Expression sequencing query
fgd3 at jc3b21.UUCP
fgd3 at jc3b21.UUCP
Wed Oct 15 13:22:44 AEST 1986
In article <139200039 at uiucdcsb>, robison at 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 at 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
More information about the Comp.lang.c
mailing list