Caveat: GCC-based analysis unreliable for Free Software [LWN.net]

Caveat: GCC-based analysis unreliable for Free Software

Posted Jan 26, 2010 22:16 UTC (Tue) by Azazel (subscriber, #3724)
In reply to: Caveat: GCC-based analysis unreliable for Free Software by marcH
Parent article: LCA: Static analysis with GCC plugins

> > x-- * x++; is actually undefined rather than unspecified[*1]
>
> Oups, sorry. It is also too convoluted. So maybe this one is unspecified but defined:
>
> ( x++ ) * x

Also undefined, I believe. Consider:

x++ * x

is equivalent to:

tmp = x
x = x + 1
tmp * x

However, C and C++ do not guarantee the order in which the last two occur, so the
final result may be:

tmp * tmp

tmp * (tmp + 1)

or something else entirely (e.g., nasal daemons) if the compiler is clever
enough to notice.

Az.

(Log in to post comments)

Caveat: GCC-based analysis unreliable for Free Software

Posted Jan 26, 2010 23:11 UTC (Tue) by marcH (subscriber, #57642) [Link]

> 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".

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.