Re: C portability is a myth

From: Flash Gordon (spam_at_flash-gordon.me.uk)
Date: 02/18/05 

Date: Fri, 18 Feb 2005 13:37:09 +0000

websnarf@gmail.com wrote:
> 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?

I'll start you off with GTK+. I use applications based on this on both
Windows and Linux so it provides at least a degree of portability.

>>>>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.

No one currently wants to run it on either 8 or 64 bit systems or
systems with 64K of memory. When they do I'll let you know. In the mean
time, how many JVMs can you find for 8 bit systems?

> 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.

So you have a bug in your code where you are either invoking undefined
behaviour or implementation defined behaviour without dealing with all
possible implementations. That is your problem.

> 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).

So you use a function from the latest standard that has approximately
one conforming implementation. That is your problem. Had you stuck to
C89 it would not have been a problem.

>>>>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.

It stated "but it takes a lot of effort" and I presented a counter
example where no effort was required because none was spent. To disprove
any absolute statement you one need to provide *one* counter example. It
was a non-trivial piece of code with a carefully optimised *design*.

> 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.

So you are saying that because you rely on things explicitly stated by
the standard as being up to the implementation it prevents everything
the language defines as being portable from being portable?

>>>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.

If you are having problems porting it then it obviously has a lot of
dependencies on either implementation defined or undefined behaviour
which are not properly documented.

>>>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.

Currently one piece of SW is running on SCO 5.0.3 through to SCO 5.0.7,
AIX 4.3, AIX 5 (well, tested but not currently used by customers),
Windows NT/XP. One of the platforms at the start was DOS. It has also
run on HP-UX and Solaris. I've previously mentioned software I had
running unchanged on a DSP processor and a Silicon Graphic Workstation.

We've had to tell some of our customers to upgrade to at least SCO 5.0.6
because the JVMs available for earlier version of SCO do *not* run a
*Java* application they also want to use.

>>>>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.

Well, I have non-trivial code that behaves the same. I also know that
Berkeley DB (a very non-trivial application) is written in C and that
runs the same on a wide range of systems.

> 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).

You obviously rely heavily on things not guaranteed by the standard. I'm
sure that if you use ActiveX in Java (which I'm told is possible) you
will have great difficulty getting that Java code to work on Linux.

>>[...] 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.

I've got this Java 1.3 JVM, can I run your Java application developed
for Java 1.4? Not sodding likely. Therefore *exactly* the same can be
said about Java.

>> > 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.

http://dictionary.reference.com/search?q=portability
    "Computer Science. Relating to or being software that can run on two
or more kinds of computers or with two or more kinds of operating systems."

If an implementation is not available for a system then you can't run
the application on it, therefore it is not portable to that system,
therefore that is a limit on portability.

http://onlinedictionary.datasegment.com/word/portability also agrees and
even states C as probably being the most portable language.

>>[...] 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.

As stated previously and not addressed by you. That means that any code
written for a language with exactly one implementation is, by
definition, completely portable even though it only runs on the one
system. That is obviously complete rubbish.

>>>>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.

See above. By your definition you can have a completely portable program
that runs on exactly one machine. Your definition also makes something
like TMS320C25 machine code extremely portable since any TMS320C25 will
run the machine code exactly the same.

>>>>[...] 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.

No, it tells you exactly what will work on all systems thus allowing you
to write portable code. It also tells you where the implementation has
to tell you about choices if you have good reason to do something
dependant on those implementation choices.

> 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.

None of which makes C any less portable than any other language. If you
find a machine which only had 4K of RAM available once the JVM is loaded
it will find it rather difficult to run a 500K Java application.

You can't say that platform limitations such as amount of memory are
applicable to C portability but not to portability of any other
language. Well, you can, but it just shows you to be trolling.

> 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.

So? Did you write a JVM for the chip? If not it is completely irrelevant
to the relative portability of C and Java. If the only language
available for it is your V language, and your V language is only
available for that chip, then why not write all your SW in V as, by your
definition (which no one else seems to agree with) and code written in V
is by definition complete portable.

> 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.

Your point is? Are you now saying that it is Forth which is portable
rather than Java or C? 

-- 
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

Relevant Pages

  • Re: C, really portable?
    ... > Wait, is Java a modern language superior to C, or is it still ... It is a much better OO language than C++, ... It depends what you are doing, Java aims for rigorous portability - the same ... regardless of platform. ...
    (comp.lang.c)
  • Re: C, really portable?
    ... My brother worked a couple of years at making Java programs ... >> the really sneaky portability problems. ... Wait, is Java a modern language superior to C, or is it still ... > platforms don't have C compilers,, doesn't ...
    (comp.lang.c)
  • Re: C portability is a myth
    ... >> Except Java provides no portability at all to any platform that ... > For example, there was a port of Java to DOS ... a free-standing environment does not. ...
    (comp.lang.c)
  • Re: Migrating C application from VMS to LINUX
    ... regardless of the platform and the porting plans. ... The Java platform can get the press and the marketeering, ... calls and other such obvious limitations, a more subtle portability ... beginning with your engineering and look at your choice of language. ...
    (comp.os.vms)
  • Re: C, really portable?
    ... >> Wait, is Java a modern language superior to C, or is it still ... It is a much better OO language than C++, ... on one platform then behave pathologically ... > It depends what you are doing, Java aims for rigorous portability - the ...
    (comp.lang.c)