home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / os / linux / 10082 < prev    next >
Encoding:
Internet Message Format  |  1992-09-08  |  2.4 KB
  1. Path: sparky!uunet!mcsun!news.funet.fi!hydra!klaava!wirzeniu
  2. From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
  3. Newsgroups: comp.os.linux
  4. Subject: Re: GCC 2.2.2d bug
  5. Message-ID: <1992Sep7.141948.20280@klaava.Helsinki.FI>
  6. Date: 7 Sep 92 14:19:48 GMT
  7. References: <1992Sep4.210545.36040@uservx.plk.af.mil> <8eToqB1w164w@kryton.UUCP>
  8. Organization: University of Helsinki
  9. Lines: 49
  10.  
  11. When discussing ``p = p++'', system@kryton.UUCP (Scott Beckstead)
  12. writes:
  13. >Indeed very poor code.  The final result will be 11.  because even if
  14. >the assign works properly the increment will still happen.  
  15.  
  16. Wrong.  There is no single correct answer (except a core dump).  The
  17. assignment and increment can happen in any order, since they occur in
  18. the same interval between two sequence points.  Go read the comp.lang.c
  19. FAQ, the standard, and any decent book on C about sequence points. 
  20. Please.  I have included an extract of the C FAQ, in order to kill this
  21. thread.  It is irrelevant to Linux, and IMHO doesn't need any more
  22. posts, since the subject has already been discussed to death in other
  23. newsgroups (c.l.c.  and comp.std.c). 
  24.  
  25. --
  26. Lars.Wirzenius@helsinki.fi
  27.  
  28. From the C FAQ:
  29.  
  30. 3.1:    Under my compiler, the code
  31.  
  32.         int i = 7;
  33.         printf("%d\n", i++ * i++);
  34.  
  35.     prints 49.  Regardless of the order of evaluation, shouldn't it
  36.     print 56?
  37.  
  38. A:    Although the postincrement and postdecrement operators ++ and --
  39.     perform the operations after yielding the former value, the
  40.     implication of "after" is often misunderstood.  It is _not_
  41.     guaranteed that the operation is performed immediately after
  42.     giving up the previous value and before any other part of the
  43.     expression is evaluated.  It is merely guaranteed that the
  44.     update will be performed sometime before the expression is
  45.     considered "finished" (before the next "sequence point," in ANSI
  46.     C's terminology).  In the example, the compiler chose to
  47.     multiply the previous value by itself and to perform both
  48.     increments afterwards.
  49.  
  50.     The behavior of code which contains multiple, ambiguous side
  51.     effects has always been undefined.  Don't even try to find out
  52.     how your compiler implements such things (contrary to the ill-
  53.     advised exercises in many C textbooks); as K&R wisely point out,
  54.     "if you don't know _how_ they are done on various machines, that
  55.     innocence may help to protect you."
  56.  
  57.     References: K&R I Sec. 2.12 p. 50; K&R II Sec. 2.12 p. 54; ANSI
  58.     Sec. 3.3 p. 39; CT&P Sec. 3.7 p. 47; PCS Sec. 9.5 pp. 120-1.
  59.     (Ignore H&S Sec. 7.12 pp. 190-1, which is obsolete.)
  60.