C portability is a myth

[websnarf]

You mean where *semantics* get added to the definition?

Except Java provides no portability at all to any platform that
isn't at least 32-bits with a multi-tasking GUI environment.

What are you talking about? A VM can emulate multitasking -- an
underlying OS which does so is irrelevant (in fact, I would be curious
to know, if in fact, the Java spec *REQUIRES* the multitasking to be
emulated, so that race conditions are limited to VM instruction
granularity.) Interfacing with GUI environments has to be done with
some kind of native method rig up, and again is not a gating factor in
the ability to run Java. And 32 bits -- are you smoking something? You
just have to present the interface, there only requirements for the
underlying machine is that it can compute something.

For example, there was a port of Java to DOS (called Kaffe, I believe.)
You are confusing what is exposed with what is required by the
platform.

[...] C on the other hand, does.

C requires the existence of files/stdio, and a system timer. Voting
machines can arguably be considered more secure if they do *NOT*
contain any system timer (consider software which waits for the
election date, or well past the start of a real election before
enacting a "flaw" -- a little hard to do without a timer).

There is a C compiler, or more likely several or dozens,
for virtually every processor architecture in existence,
from 8-bit microprocessors and microcontrollers to 64-bit
supercomputers.

Yes, but I think the OP's point is that no pair of any such compilers
accepts the same set of source inputs and does not generate
semantically compatible output for the intersection of code that is
common.

No new processor or controller is ever introduced without
some C compiler being available these days.

I am aware of at least one smart card that was -- they implemented a
picojava instruction set for it. Think about the complexities involved
in architecture design and bring up -- there can't possibly be any
since they have most of it specced out for them already.

The core of C is the most portable language in existence, has
been for a long time, and will be for a long time to come.

You misspelled *least*. Lua, Python and Perl, for example, are *FAR*
more portable. I think the only two languages I know of which are
*less* portable than C are assembly and Basic.

 

[Gregory Toomey]

Oh, jeez. Sounds like you woke up on the wrong side of the bed
there, sparky.

Gregory's comments still stand.

The OP is a moron.

gtoomey

 

[roman ziak]

BTW Things like GUI and dB access ARE fairly portable. It's called

Motif and MySQL. Heck libs like GTK+ and QT are even fairly portable
[even ported to windows].

Since when Motif, MySQL, GTK, QT became part of C ?

 

[George Wicks]

@individual.net:

Yes, I see what you mean..

The OP is a moron.

gtoomey

 

[Jesse Meyer]

You misspelled *least*. Lua, Python and Perl, for example, are *FAR*
more portable. I think the only two languages I know of which are
*less* portable than C are assembly and Basic.

Perhaps I need my coffee, but *how* is Perl and Python _FAR_ more
portable than C?

Other than endian-issues, standard c seems just as portable as
either python or perl. Assuming that endian issues are avoided
or worked around, I'm assuming its _as_ portable.

In practice, it would appear that far more architectures have a
c compiler available than a perl interpreter. Since perl is
written in c, the number of architectures that support perl
has to be less than or equal to the number of architectures
that support c.

Non-portable perl is rather easy to create: Go on CPAN and grab
a nifty module. Oopsie, its not available on win32. There goes
portability!

Just my $.02,

Jesse Meyer

 

[Stephen Sprunk]

This is definitively impressive.

You say there was about 5% of the code, which was wrapping and
abstracting different platforms so the remaining 95% code could run
without change.

I'm not sure I'd put it that way. Very little of the code cared at all what
platform it ran on; nothing is abstracted if you're simply ignoring the
details.

5% of the code couldn't ignore platform-specific details because it
consisted of device drivers and such. Since it was all custom hardware,
except for the memory and CPU, we'd have had to write that all from scratch
anyways.

This portability is not the merit of the C language nor its standard
libraries, but good design of the proprietary runtime.

What runtime? In most cases (actually, in all cases for customer-shipped
code) the software ran directly on the hardware -- no runtime, no OS, no VM,
etc. except what we provided ourselves.

~95% of the code was cleanly portable across widely different platforms;
that means that _well-written_ C code is portable.

Do you actually
think that if the language of choice of your employer was Pascal and
let's assume there would be a conforming Pascal compiler on each of
those plattforms, they would not succeed with the application ?

It might be possible, though I'm not convinced, to write the portable 95% of
the code in Pascal, Java, COBOL, Perl, or a variety of other languages.
However, that means finding suitable compilers and possibly VMs for each of
the platforms, which are clearly not as easily available as C compilers and
rarely anywhere near as fast at runtime. C is at least as portable as other
languages, and is arguably more portable.

Also important was that the nonportable ~5% could only be written in C or
ASM -- no other languages provide access to unportable constructions _even
if that's what's explicitly desired_. Try writing device drivers, VMMs, or
schedulers in Java or Pascal -- unportable extensions must be written in C
and linked in, and then your overall program becomes just as "unportable" as
a C version would be.

S

 

[Walter Roberson]

:You misspelled *least*. Lua, Python and Perl, for example, are *FAR*
:more portable. I think the only two languages I know of which are
:*less* portable than C are assembly and Basic.

Perl... Every time I load in a new perl release, I have to
spend at least a day in hacking it to make it functional on SGI IRIX.
Which often comes down to a matter of choising which test errors
to accept and force installation despite the failure.

Some of the fundamental perl modules in CPAN, including some of
the basic ones like POD to MAN conversion, are broken. Often the
only way to get them to work is to either recompile *all* of Perl
via gcc, or to hack the system header files. But these days if
I convert to gcc, then the way that gcc likes to lie about ANSI C
conformance result in conflict with SGI's namespace macros, and
if I use SGI's C compiler (which is usually quote strict on
error checking), then h2ph never gets right the conversion of
the wait structure [which is a typecast]...

All in all, -every- meaningful update I do to load in the
latest Perl or latest releases of the CPAN modules means that I
will have to spend about a full day loading, compile, debugging,
hacking. And I have to do the same thing all over again when
I go to update on Mac OSX.

A lot of the time it feels like I am spending more time on
porting and fixing perl than I am on actually -using- perl.

 

[Richard Bos]

You misspelled *least*. Lua, Python and Perl, for example, are *FAR*
more portable.

*Snigger* _Perl_? Portable? Please, tell me what you've been drinking, I
want to live in that happy world, too!

FWIW, I've got a pretty good, complete C compiler for MS-DOS. Last time
I saw the Perl interpreter for MS-DOS, almost half of its documentation
consisted of pages stating "This function has not been ported to DOS".

Richard

 

[Kevin D. Quitt]

In my opinion,

You are entitled to your beliefs; only an expert is entitled to an
opinion.

And please, before you start sending flames, please introduce the group
into your last project of porting the software between platforms. And
let it not be Win98 -> WinXp ...

Flames sent - you are clearly speaking from ignorance. Nothing wrong with
ignorance, except when you're as proud of it as you seem to be.

We developed an application over several years. It started under DOS, got
moved to pSOS on an ARM, got moved to linux on an x86, and is being moved
to another real-time OS. From DOS to pSOS the OS interface was changed -
it hasn't been changed since. New features have been added and bugs
fixed, but the application code is identical across four different
operating systems and seven hardware platforms. We still actively support
all of them except the COS version, and fixes and features are retro
fitted so older customers can have the latest.

If your example of 500 vs. 1500 hours is accurate, then you don't really
know how to program in C. I find it takes very little more time to write
pretty-much portable code than compiler/environment specific code - and
usually less time. I go back and forth between compilers and platforms -
it's rarely worth learning each compiler's extensions.

 

[websnarf]

Perhaps I need my coffee, but *how* is Perl and Python _FAR_ more
portable than C?

Code you write in Python/Perl that doesn't use use obvious native
functionality behaves identically on any platform that implements them?

Other than endian-issues, standard c seems just as portable as
either python or perl.

You can't even use an int and be sure to be portable.

[...] Assuming that endian issues are avoided or worked around, I'm
assuming its _as_ portable.

?!?! Endianness anonimity is the *least* of C's problems. Tell me, If
you cast a long to a double do you lose accuracy? If you right shift a
signed integer, what do you expect to happen?

In practice, it would appear that far more architectures have a
c compiler available than a perl interpreter.

Ok. Availability != portability. This isn't the first time I've had
to point this out in this newsgroup. Portability, means you simply
take your code and you can move it to completely different kind of
platform (with an avaiable compiler/interpretor for the language).
Perl, Python and Lua are interpreters, so they are *source* portable.
Java is a compiler that is *binary* portable. C ... well its just not
portable at all. C is *available* -- and it is even possible to write
source programs that are portable to some subset of platforms which
have C compilers.

I mean machine language is at least as "portable" as C if you are going
to claim that platform availability is what portability means.

[...] Since perl is written in c, the number of architectures that
support perl has to be less than or equal to the number of
architectures that support c.

Which has nothing to do with portability ...

Non-portable perl is rather easy to create: Go on CPAN and grab
a nifty module. Oopsie, its not available on win32. There goes
portability!

Ok, but those are native extensions. And I am sure that they are
clearly marked as such.

 

[Alan Balmer]

And the last but not least point is the justification of portability.
Say I write app in 500 hours using all possible compiler extensions.
Does it justify to write it perfectly portale and spend 1500 hours
instead ?

I suggest that you invest some of those hours in learning good program
design principles, and how to write portable code without investing
extra time.

 

[Walter Roberson]

:> Perhaps I need my coffee, but *how* is Perl and Python _FAR_ more
:> portable than C?

:Code you write in Python/Perl that doesn't use use obvious native
:functionality behaves identically on any platform that implements them?

Read the perlop man pages. It has a number of instances where it
says that various parts are implimented in terms of C types. For
example, see the descriptions of ~ and <<

:You can't even use an int and be sure to be portable.

Nor can you in perl.


:?!?! Endianness anonimity is the *least* of C's problems. Tell me, If
:you cast a long to a double do you lose accuracy? If you right shift a
:signed integer, what do you expect to happen?

And these things are well defined in perl?

erl, Python and Lua are interpreters, so they are *source* portable.

I can't speak about Python or Lua, but Perl is *not* source portable.


:> Non-portable perl is rather easy to create: Go on CPAN and grab
:> a nifty module. Oopsie, its not available on win32. There goes
:> portability!

:Ok, but those are native extensions. And I am sure that they are
:clearly marked as such.

No, there are quite a few CPAN modules which were written to
be portable, but which really aren't. They can't even get right
the pure perl modules that convert embedded comments into manual
pages.

 

[Stephen Sprunk]

Code you write in Python/Perl that doesn't use use obvious native
functionality behaves identically on any platform that implements them?

Code you write in C that doesn't rely on undefined or implementation-defined
behavior behaves identically on any conforming system.

Of course, Standard C has a far smaller space of defined behavior as well as
a much smaller standard library, but it also runs on significantly more
platforms than Perl or Python will ever run on.

As you note, availability isn't portability, but what do I care that Perl
defines a particular behavior that C doesn't when Perl doesn't run on the
dozen systems I care about? You can't port Perl when there's no runtime
available, whereas C source at least has a _chance_ of porting, depending on
how well it was written.

You can't even use an int and be sure to be portable.

That depends on whether you stick to the constraints that are guaranteed to
be portable.

Ok, but those are native extensions. And I am sure that they are
clearly marked as such.

There are many modules written purely in Perl that make no native calls but
still fail to be portable even to various POSIX systems.

S

 

[Mark McIntyre]

My point, however, was that there is certain expense on this
portability, unlike mentioned Java where portability is inherent since
plattform is same, regardless on the CPU.

Er, Java isn't portable. You have to write a nonportable JVM for every
platform first. This severely restricts portability to platforms that
support whatever is required from a JVM.

Portability is not property of the language but its implementation.

Portability is a property of the language /and/ its implementation.

 

[Alan Balmer]

Er, Java isn't portable. You have to write a nonportable JVM for every
platform first. This severely restricts portability to platforms that
support whatever is required from a JVM.

Yes. Even J2ME, the stripped-down version for embedded systems, is not
implemented on many platforms. Sun claims "millions of devices", but
that could be only one chip ;-)

 

[Jack Klein]

You mean where *semantics* get added to the definition?


What are you talking about? A VM can emulate multitasking -- an
underlying OS which does so is irrelevant (in fact, I would be curious
to know, if in fact, the Java spec *REQUIRES* the multitasking to be
emulated, so that race conditions are limited to VM instruction
granularity.) Interfacing with GUI environments has to be done with
some kind of native method rig up, and again is not a gating factor in
the ability to run Java. And 32 bits -- are you smoking something? You
just have to present the interface, there only requirements for the
underlying machine is that it can compute something.

For example, there was a port of Java to DOS (called Kaffe, I believe.)
You are confusing what is exposed with what is required by the
platform.

Is there a port of Java to PIC, 8051, AVR, ST7, or any DSP in the
world? There are C compilers for all of them, C++ for some. No Java,
Perl, Lisp, Visual Basic, C#, or any other flavor of the month.

[...] C on the other hand, does.

C requires the existence of files/stdio, and a system timer. Voting

Whatever gave you that silly, and totally wrong idea? C specifically
defines two types of implementations. A hosted environment does
indeed require stdio, a free-standing environment does not. No
implementation of C requires a system timer. There is no such
requirement in the language standard at all.

machines can arguably be considered more secure if they do *NOT*
contain any system timer (consider software which waits for the
election date, or well past the start of a real election before
enacting a "flaw" -- a little hard to do without a timer).

But your point is moot, because C does not require any sort of timer,
not in any environment. Not under any circumstances, even in a
strictly conforming hosted environment. The time() function merely
returns (time_t)-1. Period, end of story.

Heck, in 1999 I had to produce and sign documents for a variety of
systems affirming that they could not possibly have a Y2K problem
because they had no time-of-day hardware, and neither used outside
world time nor even had a method in their communications protocol of
receiving one.

Yes, but I think the OP's point is that no pair of any such compilers
accepts the same set of source inputs and does not generate
semantically compatible output for the intersection of code that is
common.


I am aware of at least one smart card that was -- they implemented a
picojava instruction set for it. Think about the complexities involved
in architecture design and bring up -- there can't possibly be any
since they have most of it specced out for them already.


You misspelled *least*. Lua, Python and Perl, for example, are *FAR*
more portable. I think the only two languages I know of which are
*less* portable than C are assembly and Basic.

You seem to think, even as computers of all sizes are being introduced
into almost everything, that the entire world is one problem domain.

The most recent estimates I have heard are that there are
approximately 1,000,000,000 CPUs/processors/controllers being
manufactured and used per year. Approximately 150,000,000, or about
15% of them, are the 32-bit and 64-bit processors used as the main CPU
in laptop/desk top/workstation/server applications, an extremely
narrow range of applications.

The other 85% cover a much wider range than that.

Take a good look at the computer you are using to view Google and read
and post messages. It has one CPU, Pentium or equivalent or perhaps a
PowerPC. How many other programmed execution units does it have?

One in the keyboard, one in the mouse, one in the hard disk drive, one
in the CD/DVD drive. One or more in the printer, another in the
router if you use one. Oh, don't forget one in the monitor.

If you have a common home desk top setup, your router could well have
an ARM in it, and might be running under a version of Linux, perhaps
with real time extensions. So most or all of the languages you
mention above are available for that platform, as well as for the main
computer's CPU.

As for the others, if they have anything available at all besides an
assembler available, it is a C compiler.

---

A proper signature line consists of "-- ", that is two dash characters
and a space. As specified by relevant RFCs. Most competent
newsreaders handle trimming automatically. Incorrect signature
delimiters are a sign of a social engineering, not a technical,
problem.

 

[infobahn]

Er, Java isn't portable. You have to write a nonportable JVM for every
platform first.

Just a nit... By the same reasoning, C isn't portable either, because
you have to write a nonportable C compiler for every platform first.

This severely restricts portability to platforms that
support whatever is required from a JVM.

....or whatever is required from a C compiler.

Portability is a property of the language /and/ its implementation.

Portability is a myth. But it is with C that the myth most closely
approaches reality.

 

[tomstdenis]

BTW Things like GUI and dB access ARE fairly portable. It's called
Motif and MySQL. Heck libs like GTK+ and QT are even fairly portable
[even ported to windows].

Since when Motif, MySQL, GTK, QT became part of C ?

Um, you do realize that the Java language doesn't include Swing and the
7000 other classes right? This argument is really retarded though so
this is what I would expect...

You're saying Java is better because it *comes with* gui and such...

Well by that token by Gentoo distro *came with* GTK+, Motif and X11.
So I don't see why I can't code guis with C with ease. Also most *nix
like platforms come with Motif and X11 [and likely GTK+]...

So what exactly is your point?

Tom

 

[tomstdenis]

This is definitively impressive.

You say there was about 5% of the code, which was wrapping and
abstracting different platforms so the remaining 95% code could run
without change.

This portability is not the merit of the C language nor its standard
libraries, but good design of the proprietary runtime. Do you

actually

....

Real software developers learn to factor their code into functional
components. For instance in Mozilla the part that decodes HTML and the
part that actually displays something should be completely separated.

That way when you port Mozilla you port the GUI code and not the HTML
engine.

This is no different for any other project... In most apps the UI can
be a relatively insignificant part of the project development....

Of course you'd know this because of your vast amounts of experience
you required to pass judgement on how bad C is...

Tom

 

[websnarf]

Is there a port of Java to PIC, 8051, AVR, ST7, or any DSP in the
world? There are C compilers for all of them, C++ for some. No Java,
Perl, Lisp, Visual Basic, C#, or any other flavor of the month.

Portability != Availability.

You seem to think, even as computers of all sizes are being introduced
into almost everything, that the entire world is one problem domain.

The most recent estimates I have heard are that there are
approximately 1,000,000,000 CPUs/processors/controllers being
manufactured and used per year.

This has nothing to do with portability.

[...] Approximately 150,000,000, or about
15% of them, are the 32-bit and 64-bit processors used as the main CPU
in laptop/desk top/workstation/server applications, an extremely
narrow range of applications.

This has nothing to do with portability.

The other 85% cover a much wider range than that.

This has nothing to do with portability.

Take a good look at the computer you are using to view Google and read
and post messages. It has one CPU, Pentium or equivalent or perhaps a
PowerPC. How many other programmed execution units does it have?

This has nothing to do with portability.

As for the others, if they have anything available at all besides an
assembler available, it is a C compiler.

This has nothing to do with portability. By your incorrect definition
of portability, assembly is far and away the most portable language.