question about potential integer truncation in default_erasesize

[PaX Team]

On 29 Sep 2015 at 14:02, Brian Norris wrote:

> > that'd
> > actually be fine for us since it means when the overflow plugin instruments
> > this code any runtime trigger means a real problem, not a false positive.
> 
> OK, good. As long as you aren't going to start complaining about
> theoretical concerns we're OK, but a dynamic check is cool.

we don't care about theoretical bugs but real ones too. the reason for asking 
about this code is that while investigating a false positive report in some
other code (that turned out to be due to a limitation in how gcc represents
certain constructs at its gimple layer) we decided to check the underlying
cause in the whole tree so that we could decide how to fix the FP. the choice
is usually either changing the source code (so that gcc produces a different
representation) or disabling instrumentation for either the particular
expression or all similar constructs. the decision comes down to how many
potentially useful checks we'd omit vs. how many more false positives we'd
risk having. in this case the code construct was copying between structure
fields of different sizes and linux has fortunately a few of these only that
can be manually verified, save for a few cases i could not decide myself, hence
this email and few others elsewhere (some turned out to be real bugs or just
inefficient code in fact).

in short, if you ever hear from us again it'll be because there was a real
integer truncation/overflow/etc event (and we'll have precise source location
for it ;).