<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 13, 2016 at 10:44 AM, Joerg Sonnenberger via cfe-commits <span dir="ltr"><<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, Sep 12, 2016 at 11:50:36PM -0000, George Burgess IV via cfe-commits wrote:<br>
> Author: gbiv<br>
> Date: Mon Sep 12 18:50:35 2016<br>
> New Revision: 281277<br>
><br>
> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=281277&view=rev" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-<wbr>project?rev=281277&view=rev</a><br>
> Log:<br>
> [Sema] Fix PR30346: relax __builtin_object_size checks.<br>
><br>
> This patch makes us act more conservatively when trying to determine<br>
> the objectsize for an array at the end of an object. This is in<br>
> response to code like the following:<br>
><br>
> ```<br>
> struct sockaddr {<br>
>   /* snip */<br>
>   char sa_data[14];<br>
> };<br>
><br>
> void foo(const char *s) {<br>
>   size_t slen = strlen(s) + 1;<br>
>   size_t added_len = slen <= 14 ? 0 : slen - 14;<br>
>   struct sockaddr *sa = malloc(sizeof(struct sockaddr) + added_len);<br>
>   strcpy(sa->sa_data, s);<br>
>   // ...<br>
> }<br>
> ```<br>
><br>
> `__builtin_object_size(sa->sa_<wbr>data, 1)` would return 14, when there<br>
> could be more than 14 bytes at `sa->sa_data`.<br>
><br>
> Code like this is apparently not uncommon. FreeBSD's manual even<br>
> explicitly mentions this pattern:<br>
> <a href="https://www.freebsd.org/doc/en/books/developers-handbook/sockets-essential-functions.html" rel="noreferrer" target="_blank">https://www.freebsd.org/doc/<wbr>en/books/developers-handbook/<wbr>sockets-essential-functions.<wbr>html</a><br>
> (section 7.5.1.1.2).<br>
><br>
> In light of this, we now just give up on any array at the end of an<br>
> object if we can't find the object's initial allocation.<br>
><br>
> I lack numbers for how much more conservative we actually become as a<br>
> result of this change, so I chose the fix that would make us as<br>
> compatible with GCC as possible. If we want to be more aggressive, I'm<br>
> happy to consider some kind of whitelist or something instead.<br>
<br>
</div></div>IMO this should be restricted to code that explicitly disables C/C++<br>
aliasing rules.</blockquote><div><br></div><div>Do you mean -fno-strict-aliasing or -fno-struct-path-tbaa or something else here? (I think we're not doing anyone any favours by making _FORTIFY_SOURCE say that a pattern is OK in cases when LLVM will in fact optimize on the assumption that it's UB, but I don't recall how aggressive -fstruct-path-tbaa is for trailing array members.)</div></div></div></div>