[cfe-dev] CLang 2.1 doesn't catch assert within if

[David Blaikie]

>
> 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:

if (foo)
#ifndef NDEBUG
  printDebugInfo();
#endif
doImportantProductionWork();

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

- David


>
> Ever Faithful,
>
> Don Quixote
> --
> Don Quixote de la Mancha
> Dulcinea Technologies Corporation
> Software of Elegance and Beauty
> http://www.dulcineatech.com
> quixote at dulcineatech.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20111007/f915c4c8/attachment.html>