Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!caip!clyde!bellcore!ulysses!mhuxr!mhuxn!ihnp4!inuxc!pur-ee!uiucdcs!uiucdcsb!robison
From: robison@uiucdcsb.cs.uiuc.edu
Newsgroups: net.lang.c
Subject: Re: Expression sequencing query
Message-ID: <139200039@uiucdcsb>
Date: Sat, 4-Oct-86 18:39:00 EDT
Article-I.D.: uiucdcsb.139200039
Posted: Sat Oct  4 18:39:00 1986
Date-Received: Tue, 7-Oct-86 19:34:22 EDT
References: <111@titan.UUCP>
Lines: 49
Nf-ID: #R:titan.UUCP:-11100:uiucdcsb:139200039:000:2635
Nf-From: uiucdcsb.cs.uiuc.edu!robison    Oct  4 17:39:00 1986


>      (2) I reviewed K&R for some light on what result the first and second
> expressions should produce.  I found the following sentence on page 49:
> "As mentioned before, expressions involving one of the associative and
> commutative operators (*, +, &, ^, |) can be rearranged even when
> parenthesized."  And people call BASIC brain-damaged!  This means
> 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?
>

1.   It is not a flaw in a language to specify certain constructs as undefined.
     If the C compilers were not allowd to re-arrange expressions, then the 
     results could be exactly defined, at the cost of slowing the program down. 
     On page 50, K&R points out that "the best order strongly depends on machine
     architecture".  C was designed for writing efficient programs on a variety 
     of machines.
 
2.   The operations *,+,&,^,| are commutative and associative in mathematics.
     To write code depending on a particular evaluation order is a very poor
     practice.  The meaning of the code may be obvious to you, but other
     readers will most likely be mislead.  Programmers should strive for clarity
     of expression.

3.   Determinism is not always a good thing, for example it can slow down 
     parallel processors.  Some languages (e.g. Dijkstra's guarded commands)
     may not give you the same result on the same machine.

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.

In short, C's undefined constructs are not a flaw and do not deter writing
portable code.

Arch D. Robison					robison@uiucdcs
University of Illinois at Urbana-Champaign