<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, 16 Oct 2015 at 01:32 Matt Caswell via RT <<a href="mailto:rt@openssl.org">rt@openssl.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 15/10/15 20:53, Alexander Cherepanov via RT wrote:<br>
> On 2015-10-15 15:41, Matt Caswell via RT wrote:<br>
>> The purpose of the sanity check is not then for security, but to guard<br>
>> against programmer error. For a correctly functioning program this test<br>
>> should never fail. For an incorrectly functioning program it may do. It<br>
>> is not guaranteed to fail because the test could be compiled away but,<br>
>> most likely, it will. We can have some degree of confidence that the<br>
>> test works and does not get compiled away in most instances because, as<br>
>> you point out, an explicit check for it appears in packettest.c and, to<br>
>> date, we have had no reported failures.<br>
><br>
> What was not entirely clear from the original bug report is that, while<br>
> the check is not compiled away, it's compiled into something completely<br>
> different from what is written in the source. Specifically, the check<br>
> "buf + len < buf" is optimized into "len >> 63" on 64-bit platform, i.e.<br>
> "(ssize_t)len < 0" or "len > SIZE_MAX / 2". This is not a check for<br>
> overflow at all, it doesn't even depend on the value of "buf".<br>
><br>
> If this is what was intended then it's better to write it explicitly. If<br>
> this is not what was intended then some other approach is required.<br>
<br>
I'd say that is an instance of the compiler knowing better than us how<br>
big |len| would have to be in order to trigger an overflow. Those rules<br>
are going to be platform specific so we should not attempt to second<br>
guess them, but instead let the optimiser do its job.<br></blockquote><div><br></div><div>If it is, then the compiler is wrong, surely? e.g. if buf is 0xfff...fff, and len is 1, you get an overflow, which the optimised version does not catch.</div><div><br></div><div>What I'm not understanding from this thread is what the argument is against avoiding undefined behaviour?</div><div><br></div></div></div>