<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sat, 17 Oct 2015 at 06:35 Kurt Roeckx 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">On Fri, Oct 16, 2015 at 09:44:22PM +0000, Kaduk, Ben via RT wrote:<br>
> On 10/16/2015 04:35 PM, Kurt Roeckx via RT wrote:<br>
> > On Fri, Oct 16, 2015 at 06:50:36PM +0000, Kurt Roeckx via RT wrote:<br>
> >> On Fri, Oct 16, 2015 at 04:50:59PM +0000, Matt Caswell via RT wrote:<br>
> >>> In a well-behaved program there is no undefined behaviour. The "buf +<br>
> >>> len < buf" check will always evaluate to false, so in that sense is<br>
> >>> useless but it *is* well defined.<br>
> >> The defined behaviour for the "buf + len" part is as far as I know<br>
> >> that you're that the pointer should point inside the allocated<br>
> >> object or 1 byte after it.  So as long as "len" is in the valid<br>
> >> range, the "buf + len" part should be well defined.  The test with<br>
> >> -1 is clearly undefined.<br>
> >><br>
> >> As far as I know in the comparison pointers they should point<br>
> >> to the same object.  But the check seems to imply that they might<br>
> >> not point to the same object or that buf is not the base of the<br>
> >> object.  But since len is unsigned only the option that they don't<br>
> >> point to the same object seems to be left.<br>
> >><br>
> >> So it's unclear to me if this is defined behaviour or not.<br>
> > So thinking about this some more, it seems to be a check for<br>
> > undefined behaviour that probably itself is still defined.<br>
> ><br>
> > That probably also means the compiler can assume that it's always<br>
> > false and eliminate the check, it's probably just not smart enough<br>
> > yet.<br>
> ><br>
><br>
> I think it is unambiguous that there are values of unsigned char *buf<br>
> and size_t len for which evaluating (bug + len < buf) invokes undefined<br>
> behavior -- the sheer act of performing the addition buf + len can<br>
> produce undefined behavior, even before any comparison.  I am as-yet<br>
> uncertain whether the case when buf points into the middle of an object<br>
> and len is (size_t)-1 invokes undefined behavior, but I am inclined to<br>
> believe that it is also undefined behavior.<br>
<br>
Just to clarify what I mean, buf + len can both have defined and<br>
undefined meaning, it depends on the value of len, so the compiler<br>
can probably not say anything about that part without knowing all<br>
the callers of that code.  As long as it has a defined meaning the<br>
compiler will probably do it.  buf + len < buf also seems to have<br>
a defined meaning, but in all defined meanings it's false, and so<br>
the compiler can just optimize that part away.<br>
<br>
Anyway, I would really like this to be changed.<br></blockquote><div><br></div><div>+1</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Kurt<br>
<br>
<br>
_______________________________________________<br>
openssl-dev mailing list<br>
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-dev" rel="noreferrer" target="_blank">https://mta.openssl.org/mailman/listinfo/openssl-dev</a><br>
</blockquote></div></div>