Re: address warnings from GCC's UB sanitizer

[Akim Demaille]

Hi Paul,

> Le 20 mars 2019 à 05:41, Paul Eggert <address@hidden> a écrit :
> 
> 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....

Sorry, I was unclear.  Yes, we are discussing about a piece of code from bison 
itself, not the generated parsers.  But they share the same configure.ac, and I 
find much easier to that both bison and the generated parser be tested with 
(about) the same set of warnings (actually, the test suite uses _more_ flags, 
but at least it gets all the ones applied to bison).

I'm not using the warning flags -Wtype-limits and don't use 
-Wtautological-constant-out-of-range-compare explicitly, so I guess I inherit 
from them via some other flags like -Wextra.  To avoid having gaps in my 
coverage of warning flags applied by the test suite on generated parsers, I 
prefer avoiding -Wno- etc.

I'll do it if I must, but I'd just prefer avoiding.


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

That could very useful, indeed!

At some point I'd like to try fuzz testing the generated parsers and bison; 
then intprops.h will probably be a precious tool.