[cfe-dev] CLang 2.1 doesn't catch assert within if
dblaikie at gmail.com
Fri Oct 7 23:27:56 PDT 2011
> Yes, you are completely correct. I ALWAYS put semicolons after
> asserts, to make them look like any other function call.
Indeed, even for the correct definition of non-debug assert ((void)0) you
would need a semicolon after it to ensure the next function call was
correctly parsed. (eg, this: "((void)0) func();" should fail to compile).
> But I am COMPLETELY CERTAIN that putting an assert() inside of an if
> statement without also placing it in a Basic Block totally broke my
> VC++ code. The program I was integrating my library with was a
> financial package that produced graphs. If I graphed the output from
> both my library and the client's old library, with my assert inside
> the if, those two graphs subtly diverged. When I fixed my code to use
> a Basic Block instead, the two graphs coincided perfectly.
It'd be really interesting to see the repro so we could see what we're
actually dealing with/trying to address.
> I still have the Visual Studio 7.0 installer. I'm not sure but I
> think 7.1 is an update one can download from Microsoft's site. I
> could install them both then just have a look at <assert.h> to see how
> it is defined.
I'd love to see what was going on.
> Even if all modern compilers do the right thing, I assert (!) it would
> still be useful to write the analysis, as it would catch portability
> problems. There are lots of coders who still use broken old
> compilers. I still hear about people using Visual Studio 6!
Certainly they are, though it might be a lesser priority for clang to try to
address such broken standard libraries.
As for the general problem of non-debug builds possibly changing control
flow that could be an interesting puzzle (& even in the presence of well
behaved standard libraries it could still be a problem:
) for the static analyzer to possibly play with, but I do wonder if it might
produce a lot of false positives on code that might be legitimately trying
to change behavior under debug builds in some way or another. Might require
a fair few heuristics to reduce that noise - though that's not necessarily a
reason not to try it out & see what it looks like.
> Ever Faithful,
> Don Quixote
> Don Quixote de la Mancha
> Dulcinea Technologies Corporation
> Software of Elegance and Beauty
> quixote at dulcineatech.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev