| |||||||||||||
Caveat: GCC-based analysis unreliable for Free SoftwareCaveat: GCC-based analysis unreliable for Free SoftwarePosted Jan 26, 2010 23:11 UTC (Tue) by marcH (subscriber, #57642)In reply to: Caveat: GCC-based analysis unreliable for Free Software by Azazel Parent article: LCA: Static analysis with GCC plugins
> tmp * tmp
> or > tmp * (tmp + 1) > or > something else entirely
I think it is NOT "something else entirely", but either the first or the second. This is what I meant by "unspecified but defined".
(Log in to post comments)
Caveat: GCC-based analysis unreliable for Free Software Posted Jan 28, 2010 4:35 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]
Evaluation of an expression that involves reading and writing the same memory location, or writing to it twice, has undefined behaviour, except where (1) a single operation combines reading and writing (e.g. ++) (2) the two operations are ordered by a 'sequence point'. (Note that 'sequence points' are not actually points in a sequence, but define a partial ordering relation.)
Caveat: GCC-based analysis unreliable for Free Software Posted Jan 28, 2010 9:59 UTC (Thu) by marcH (subscriber, #57642) [Link]
My bad, I trusted Paragraph 7.12 "Order of evaluation" in Harbison and Steele's venerable "C Reference manual". Quoting it:
> but the effect will be as if it chose one argument, evaluated fully, then chose another argument, > [...] > similar holds for binary expressions
Search "but the effect will", page 254 in: http://www.careferencemanual.com/errata.htm
Anyway I doubt there is any good reason to ever throw a side-effect into a larger expression. I find this discussion entertaining, but actually relevant to bad programmers only.
|
|||||||||||||