🚀 go-pugleaf

In article <139200039@uiucdcsb>, robison@uiucdcsb.cs.uiuc.edu writes:
> 
> > the results of the first two expressions are unpredictable without
> > knowledge of the specific C compiler involved....
> > ...I believe that is a serious flaw in the
> > language definition.  Two C compilers, both correctly following the
> > definition in K&R, can compile the same legal C expression and come up
> > with different results.  Oh, well.  Who said C was a portable language?
> 
> 4. Programs are portable if written properly, i.e. pay heed to K&R's warnings.
>      I use to port and maintain programs for a large computer company.
>      The company has a "portable" language which supposedly runs identically
>      on all its various processors.  Therefore the programmers should never
>      have to worry about machine-dependencies.  Those programs were difficult
>      to port, because the language did NOT run identically on all 
>      processors, and the programmers never bothered to think about the
>      implications.
> 
> 5.   In contrast to (3), I have written a large program in C which runs on
>      VAX's, PCs, and the CRAY.  The port to the PC/RT took 13 minutes, because
>      I took time when writing to avoid portability problems.
> 
> 
> Arch D. Robison					robison@uiucdcs
> University of Illinois at Urbana-Champaign

     Your examples support my point: a _portable_ language is one which
runs identically on all implementations.  A language which permits the code
generated by its statements to be implementation-dependent is not portable.
When dealing with a non-portable language (like C) you can work around the
problem by avoiding those statements which are evaluated in an
implementation-dependent way.  But if portability is important to you--and
I believe it should be--then it is a flaw in the language definition to
permit the evaluation of statements which are syntactically correct to
depend on the implementation.

     In (4) above you describe a language which was supposed to be portable
but wasn't.  Failing to work around the non-portable features caused
problems.  In (5) above you describe a C program which was portable
specifically because you "took time when writing to avoid portability
problems."

Fabbian Dufoe
  350 Ling-A-Mor Terrace South
  St. Petersburg, Florida  33705
  813-823-2350

UUCP: ...akgua!akguc!codas!peora!ucf-cs!usfvax2!jc3b21!fgd3