Re: C portability is a myth

websnarf_at_gmail.com
Date: 02/18/05 

Date: 17 Feb 2005 17:51:30 -0800

Flash Gordon wrote:
> Actually C provides exactly *one* method of interfacing to libraries.

> It's just what libraries are available that varies. However, there
are
> cross platform GUIs.

That are actively maintained, actually function, work in C (not C++)
and which have non-trivial availability?

> >>Strange that so many of us (including me) are working on SW
> >>that uses common source files and behaves the same on multiple
> >>implementations.
> >
> > Ok, but how do you know they behave the same on multiple
> > systems? Have you tested it on a 8, 16, 32, 64 bit system,
> > each of which may use either 1s complement or 2s complement?
> > Have you ensured that you have used no more than 64K of data
> > (this is apparently the only thing that's guaranteed by the
> > standard)?
>
> It was developed on a 16 bit system and is currently used on
> 32 bit systems of both endiannesses.

So I'll take that as a no.

I thought my bignum library was complete long time ago -- it works on
16, and 32 bits under assumption that the underlying "int" is 16, 32 or
64 bits. But my Euler totient function is going crazy on at least one
pure 64 bit system with 64 bit scalars for numbers of with around 100
bits. Its damn annoying, but I've got it narrowed down (its not the
factoring or primality testing, so its somewhere in the glue code), and
this looks like the final bug.

Even for something as simple as "The Better String Library", I had to
waste about a day to make it port to all the various platforms I have
access to. And that's a library I had high confidence was portable
right out of the box. Of course it was the C standard itself which was
the culprit in causing the porting problems (vsnprintf being available
on only some systems, and having wildly different return value
semantics even on systems that do support it -- and *blaming* a
compiler vendor doesn't get me any closer to a successful port).

> > > Also strange that I managed to debug some embedded SW
> > > by writing a test harness for it on a Silicon Graphic
> > > workstation and then building and running the module
> > > on the workstation before taking the *unmodified*
> > > sources back to my normal development system and
> > > compiling them *still* *unmodified* for a DSP processor
> > > and it worked.
> >
> > Ok, but that's a representation of engineering resources. I
> > *too* write very portable code, but it takes a lot of effort.
>
> Not if you know what you are doing. This code took no extra
> effort. In fact, I did not even think about portability. It
> just worked.

Ok, but I am willing to bet that our code simply isn't comparable. For
example, my BigInt library is totally compatible with all the 2s
compatible tricks from HAKMEM, uses aggressive methods for tesing
primality and factoring numbers, and fully supports parameters aliasing
with some sort of attention being paid to efficiency. Its not as easy
as you may think.

> > For example, I have recently been porting a big integer
> > library, and it has taken me two weeks so far to support
> > it on 16, 32, and 64 bit systems with 6 different compilers.
> > I am down to my last scenario which is 64-bit on a big
> > endian 64-bit system, which I haven't got quite right yet.
> > I have decided that supporting 1s complement or systems that
> > don't sign extend signed integers will simply have to be
> > ignored.
>
> Sounds like the code was badly written.

On what grounds do you say this? The algorithms are complicated, and
if I expect to have any hope of efficiency for large numbers, I have to
pay a lot of attention to exact representation of the scalars used.
I've used the "limits.h" constants everywhere, but that just isn't
enough.

> > I mean the fact that its possible to write portable code
> > that is non-trivial in C, I kind of equate to the ability
> > to write obfuscated C code, or writing quines or whatever.
> > Yeah its possible but its a big waste of time, and at the
> > end of the day, after investing massive amounts of time
> > accomplishing these ports one at a time you wonder what
> > exactly you have accomplished.
>
> It does not take me vast amounts of extra effort.

Well, if you are writing command line text utilities for UNIX that
assume total input is less than 64K, I am not surprised. Let me know
when you've got a Windows 3.1 and Mac OS 9 port of your application
done.

> > > I've seen at least one C to Java Bytecode compiler (I
> > > don't know how complete or conforming it is) so if it
> > > runs Java Bytecode then there is at least one C compiler
> > > (however bad) that targets it.
> >
> > Ok what other C compiler is that instance compatible with?
>
> If it follows the standard, then it is compatible with all
> other C compilers that follow the standard.

This is the most ridiculous thing I've ever heard. I have never
encountered any pair of C compilers that I couldn't write natural fully
ANSI compliant code for that produced two entirely different results.
The ANSI C standard itself does not specify a model for what the output
is supposed to do that is in any sense portable.

And I've got 4 different 32-bit x86 C compilers that all produce Win32
code installed on my machine -- we're talking about the exact same
platform, all compliant with the exact same version of the ANSI C
standard -- its sad, no two of them generate the same semantic results
for generic C code. Writing useful Open Source, even if I am just
targetting Win32 on x86 requires writing the code, then porting it *3
times* (or doing the typical lame cop out of telling everyone to use
gcc).

> [...] If not, then you still have a "C" compiler targeting
> all systems with a Java implementation where all such
> implementations will behave as closely for C as they do for
> Java, thus making C at least as portable as Java by your
> definition.

No, it makes *THAT* C compiler (which is OT on comp.lang.c, BTW)
portable. That's sort of like saying C is portable so long as you just
use gcc.

> > Portability != Availability.
>
> So you keep saying.

So you (and others) keep ignoring. Look, I given a link to an online
dictionary definition. I don't know what else to do.

> [...] However, you fail to understand that portability is the
> ability to port to different systems, therefore lack of an
> implementation (or sufficiently functional implementation) on
> all platforms is a limiting factor on portability.

No, its a limiting factor on availability. Whether or not code is
portable is a charactistic of the code, or the language that the code
conforms to, and nothing more.

> > > Can you provide me with a Java implementation for the
> > > TMS320C25 I used to write SW for?
> >
> > Portability != Availability.
>
> That does not stop availability being a limiting factor on
> portability.

Availability is a limiting factor to availability. It has nothing to
do with portability.

> > > [...] How about the Perl implementation? This processor
> > > only has a *maximum* of 64K program address space and 64K
> > > data address space and our target HW had at most 8K of each.
> >
> > Dunno, but you should try out LUA on it. Either way I don't
> > think that processor will ever be able to run my (or any other
> > serious) multiprecision integer library.
>
> I don't think your desktop PC will ever be certified to be fitted
> in a military jet. Your point is?

My point is that since the ANSI C standard *itself* abandons
portability as any kind of goal, of course it can be implemented
anywhere by sheer brute force effort. Of course "BASIC" had this exact
same property. The fact that you can run a C compiler on that platform
doesn't say *anything* about portability -- because the limiting factor
to the portability is going to be the capabilities of that platform.
The ANSI C standard cannot make that platform portable, and neither
does the availability of a C compiler for it. Most code isn't portable
to this lame device because the platform can't run any sort of portable
execution environment on it.

When I worked at a start up, we created a hardware device with lots of
severe limitations and weirdnesses about it as well. Some of the
developers insisted that we needed to port a C compiler to it, but we
aborted half-way through the effort and instead ended up with a
language we called "V", which was some C-like thing, but was really
more taylored to the capabilities and limitations of the chip. While
some developers still wanted the language to evolve to C, the vast
majority of us recognized that that simply didn't add any real value
add -- certainly it would not give us any hope of portability with
*any* other C platform.

For a platform as small as that, chances are C is just the wrong
language for it. It seems comparable to an APPLE ][ or Commodore 64.
And on that kind of a platform, a language like Forth seems more
appropriate. 

---
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Relevant Pages

  • 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: removing a loop cause it to go at half the speed?
    ... The concepts are also useful because they are well defined by the same standard that defined the C language. ... If the standard says it is undefined behaviour then even if your implementation defines it you know that you will have to check whether it is documented for *every* system you want to use it on in the future, and you may well come across a system which leaves it completely undefined and possibly even causes random behaviour. ... or you will have on some other platform. ... Portability is not always easy or possible, but the starting point is knowing what the C standard guarantees and what it doesn't. ...
    (comp.lang.c)
  • Re: <ctype.h> toLower()
    ... See the C Standard. ... >> tolower() is implemented. ... >> platform, without even having to know which character set is used on that ... is, however, an error in portability for me to *call* that macro. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Standard Ada Preprocessor
    ... because Ada cannot deal with the portability issues. ... > you are interfacing directly to some special-purpose hardware. ... by their nature not compiler ... one platform you get 3 members back, and on another you get 5, ...
    (comp.lang.ada)
  • Re: C portability is a myth
    ... Windows and Linux so it provides at least a degree of portability. ... *Java* application they also want to use. ... > platform, all compliant with the exact same version of the ANSI C ... even states C as probably being the most portable language. ...
    (comp.lang.c)
Loading