| |||||||||||||
Caveat: GCC-based analysis unreliable for Free SoftwareCaveat: GCC-based analysis unreliable for Free SoftwarePosted Jan 26, 2010 12:54 UTC (Tue) by marcH (subscriber, #57642)In reply to: Caveat: GCC-based analysis unreliable for Free Software by pjm Parent article: LCA: Static analysis with GCC plugins
> If I understand the suggestion correctly, then the results would still be specific to a single preprocessor output.
Yes, I was only commenting on the evaluation order example. I feel like this specific example does not really make shine your argument.
> By using less of gcc, there's more work for the analysis code to do. For example, you need to work out what all the valid evaluation orders are, and all the possibilities for other things unspecified in C.
Yes. But I do not think you can seriously escape from working out all the possible evaluation orders, can you? Apart from switching to a better specified language (or to one discouraging side-effects). Because even gcc could change its evaluation order from one release to the next.
> 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
(Log in to post comments)
Caveat: GCC-based analysis unreliable for Free Software Posted Jan 26, 2010 14:14 UTC (Tue) by pjm (subscriber, #2080) [Link]
> But I do not think you can seriously escape from working out all the possible [behaviours of unspecified constructs], can you?
We should clarify that one needn't explicitly enumerate the possible behaviours, but yes, the fact that there are many valid behaviours for a given set of .c/.cc files is ultimately why analysis using gcc plugins doesn't in general give reliable results for Free Software (in the sense more precisely described in my initial post).
Caveat: GCC-based analysis unreliable for Free Software Posted Jan 26, 2010 21:22 UTC (Tue) by paulj (subscriber, #341) [Link]
A static analyser should be able to warn just fine about multiple stores to
objects in the same sequence point (aliases excepted). Such code is inherently buggy.
Caveat: GCC-based analysis unreliable for Free Software Posted Jan 26, 2010 22:16 UTC (Tue) by Azazel (subscriber, #3724) [Link]
> > 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
However, C and C++ do not guarantee the order in which the last two occur, so the
tmp * tmp
or
tmp * (tmp + 1)
or something else entirely (e.g., nasal daemons) if the compiler is clever
Az.
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.
|
|||||||||||||