About this code / suggested patch :


> In src/dispnew.c:6402, height and width should probably be unsigned. The
> checking by
> INT_ADD_RANGE_OVERFLOW results in a compiler warning about integral
> constant overflow
> because it tries to compute (INTMIN - 2) which obviously is out of range.
> The value is not used in this case, but the compiler may emit the warning
> anyway.

You wrote :

We don't need to modify the mainline Emacs code in order to
pacify third-party compilers that issue incorrect warnings.
We can safely ignore these warnings and leave the code alone.

And next :

2012/2/29 Paul Eggert <eggert@cs.ucla.edu>

> >> We don't need to modify the mainline Emacs code in order to
> >> pacify third-party compilers that issue incorrect warnings.
> >
> > What is incorrect about that warning?
>
> As Fabrice explained, the warning is about code that is never executed
> on his platform, because it's inside a conditional that is always
> false, and so the bug cannot possibly occur.
>
> The conditional itself is a constant, and decent compiler
> will optimize away the code in question.  The conditional is present
> precisely to avoid the overflow that the compiler is mistakenly warning
> about.  There is no easy way to rewrite the code that will both
> pacify the broken compiler and keep the code modular and portable.
>
> Cases like these are an an easy call: leave the code alone and
> ignore the bogus warning.  If possible, pass a flag to the compiler
> telling it not to issue bogus warnings like that.  Or get the
> compiler bug fixed.  Whatever.


The constant is generated by the preprocessor.
So it is not a compiler bug but a good catch from the compiler.
Luckily, the code is not executed. Given the rather deep stack
of macros, if it were executed without any warning, it would be
difficult to catch by hand.

-- 
Fabrice