home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / os / linux / 9928 < prev    next >
Encoding:
Internet Message Format  |  1992-09-07  |  1.5 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: <1992Sep5.085026.12800@klaava.Helsinki.FI>
  6. Date: 5 Sep 92 08:50:26 GMT
  7. References: <1992Sep4.202913.14346@hippo.ru.ac.za> <1992Sep05.013320.2317@kithrup.COM>
  8. Organization: University of Helsinki
  9. Lines: 27
  10.  
  11. dje@cygnus.com (Doug Evans) writes:
  12. >Pieter Immelman (pi@oliver.sun.ac.za) wrote:
  13. >: I have found that gcc is generating the wrong code for the following
  14. >: code fragment:
  15. >: 
  16. >:   int p = 10;
  17. >:   p = p++;
  18. >
  19. >My, albeit limited, reading of the standard says that the behaviour
  20. >is "unspecified" - the implementor can choose what happens.
  21.  
  22. It's undefined behaviour.  The problem is that the program alters the
  23. same memory location multiple times between two sequence points (which
  24. are points in execution when all side effects of previous expressions
  25. are guaranteed to have been completed).
  26.  
  27. There are two things which a compiler can do about undefined behaviour:
  28. make it work in one way or another, even if it might be unobvious to
  29. some people, or make it produce spectacular effects (core dumps, clay
  30. pidgeons flying out of the user's ears, etc).  The latter is, of course,
  31. preferred, since it makes the problem more obvious than either incorrect
  32. output, or code that just happens to work right.  But as far as
  33. correctness is concerned, any output at all, or even no output, is
  34. legal.
  35.  
  36. --
  37. Lars.Wirzenius@helsinki.fi
  38.