Re: C portability is a myth

From: Stephen Sprunk (stephen_at_sprunk.org)
Date: 02/18/05 

Date: Fri, 18 Feb 2005 02:01:28 -0600

<websnarf@gmail.com> wrote in message
news:1108667511.112675.224790@c13g2000cwb.googlegroups.com...
> Stephen Sprunk wrote:
> > Availability is one (of many) components of portability. Nobody is
> > claiming they're equivalent, but they're related.
>
> They are different compontents related by a problem manifested by the C
> language standard. Namnely: can you compile and run a given set of C
> source code. Having a compiler on a platform is supposed to give you
> some hope that its possible, but the path is usually convoluted unless
> the program is extremely trivial (like a Unix text processing utility.)

I and others have cited nontrivial C projects that are portable.

> Look, the distinction is just a matter of english:
>
> When one "ports" a piece of code, one is not talking about the
> solicitation for the availability of a compiler for a given platform.
> One is implicitely assuming there is some other target platform with a
> different compiler, and one engages in the activity of "porting"
> (changing the code -- not installing some compiler.)

One cannot port code to a system that has no compiler or JVM available.
There are additional components to porting, but the first step is
availability.

> When an application becomes "ported", this means that the application
> has been modified (including the rare possibility of no changes.)
> Nobody would say an application becomes "ported" when a new platform or
> compiler becomes available and the sources happen to work on it.

When I say code is "ported", that means I've compiled and tested the code on
the new platform and it appears to work. If the source is pure Standard C
with no extensions or abuse of UB or IDB, then I can be sure my code is
_portable_.

"Porting" is typically painful because most C source is not strictly
compliant with the standard or uses extensions or libraries that are not
available on the new platform. That is not C's fault -- it's the
programmer's for straying from the Standard.

Of course, one can complain the Standard doesn't cover enough features to be
useful to you, but every feature added will inevitably reduce the
availability of conforming implementations.

> When one uses a "portability layer" they are not referring to something
> like a "compiler emulator" or cross compiling, or some kind of compiler
> detection. Its usually a library module, or source modification tool
> that makes a body of code be of such a manifestation that it can run on
> multiple platforms more easily irrespective of compiler availability.

That "portability layer" is an attempt to cover up the use of extensions or
libraries that are not actually part of Standard C.

> If I am "porting" a piece of code or library, I am not trying to make a
> compiler available on a platform. I am just in the process of
> modifying it to make it work on a target platform. A system developer
> might port a compiler or generate one for a new system, but this is a
> port in of itself for the purpose of making a compiler available. For
> example when AMD and SUSE first ported gcc over to AMD64, they
> didn't take credit for "porting" the rest of the open source universe to
> their platform;

Of course not; porting a compiler does not imply porting anything else.
However, it is a necessary step before one _can_ port anything else.

> and the ANSI C standard can't take credit for it either --
> because after that was done each application then had to be "ported"
> all over again

And the work required for each port depends directly on how far the code in
question has deviated from the Standard.

> (because there's no guarantee that they'll work -- you
> have to test it).

Yes, testing is a part of porting code.

> Now if one creates a JVM for a platform (thus making it "available"),
> does that mean they have "ported" all the Java applications onto that
> platform?

Not until you've run and tested all of them -- and they work.

> At best you can say that the Java *standard* ported the
> applications.

As others have said, just because an app is written in Java doesn't mean it
can be successfully ported to all implementations.

Standard C source is portable to all conforming implementations because, by
definition, an implementation is conforming only if it correctly translates
Standard C source. Your problem seems to be with code that is _not_
Standard C or with implementations that are _not_ conforming.

S 

-- 
Stephen Sprunk        "Stupid people surround themselves with smart
CCIE #3723           people.  Smart people surround themselves with
K5SSS         smart people who disagree with them."  --Aaron Sorkin

Relevant Pages

  • Re: interesting use of NEXT SENTENCE vs. CONTINUE
    ... These days I don't do compiler maintenance, but I HAVE done in the past, so ... You had a chance to point out how adherence to the standard can improve ... >> compile it WITH MINOR MODIFICATIONS for a specific platform. ... > platform-specific extension to COBOL ...
    (comp.lang.cobol)
  • Re: interesting use of NEXT SENTENCE vs. CONTINUE
    ... I DID think any old compiler would be able to ... > compile it WITH MINOR MODIFICATIONS for a specific platform. ... > not going to go to the Standard to see what SHOULD work. ... If you write your COBOL code avoiding the things that are marked as ...
    (comp.lang.cobol)
  • Re: interesting use of NEXT SENTENCE vs. CONTINUE
    ... > implementations that purport to conform to a COBOL standard is to write ... I DID think any old compiler would be able to ... compile it WITH MINOR MODIFICATIONS for a specific platform. ... >> Portability depends on where you plan to port (or more likely where ...
    (comp.lang.cobol)
  • Re: <ctype.h> toLower()
    ... I need to link in the standard C library. ... The output of a compiler is generally called an object file. ... a call to tolower() is a call to tolower, ... platform, without even having to know which character set is used on that ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Is this Standard C++: int main(int argC, char* argV[])?
    ... > I believe you are right about the intent. ... I will point out that the Standard uses the term /definitions/ in: ... All implementations shall allow both of the following definitions of main: ... > compiler vendor I've seen will accept different naming of the arguments. ...
    (comp.lang.cpp)