Akim Demaille wrote:
Sure. Except that I don't explicitly ask for it. So I'd have to check for the
-Wno- options, and make sure not to use it in the test suite (people do compile
the generated parsers with all sorts of crazy options). So eventually it
becomes more difficult to use INT_ADD_WRAPV that directly the computation.
Wait, I thought we were talking about code in Bison itself? If it's a generated
parser, surely it can't rely on intprops.h....
I think I'll stay with the following version, unless you object to it.
Sounds OK to me. It's not worth worrying about for this particular case.
Bison undoubtedly has lots of other opportunities for integer overflow. Most of
them will never occur in ordinary practice and given Bison's audience it's
probably overkill to worry about them. However, if you do want to make Bison
bulletproof then intprops.h (or something like it) is the way to go; it's been
stress-tested on several projects to defend against the problem. These projects
use a ton of warning flags, and they carefully filter out the counterproductive
ones.
I suppose I could disable the warnings in intprops.h too, to make it easier for
other projects to use.
