<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 23, 2014 at 3:47 PM, Duncan P. N. Exon Smith <span dir="ltr"><<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On 2014-Sep-15, at 16:01, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
>> On Mon, Sep 15, 2014 at 3:51 PM, Justin Bogner <<a href="mailto:mail@justinbogner.com">mail@justinbogner.com</a>> wrote:<br>
>> David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> writes:<br>
>> > On Fri, Sep 12, 2014 at 2:22 PM, Justin Bogner <<a href="mailto:mail@justinbogner.com">mail@justinbogner.com</a>> wrote:<br>
>> ><br>
>> >     Author: bogner<br>
>> >     Date: Fri Sep 12 16:22:55 2014<br>
>> >     New Revision: 217708<br>
>> ><br>
>> >     URL: <a href="http://llvm.org/viewvc/llvm-project?rev=217708&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=217708&view=rev</a><br>
>> >     Log:<br>
>> >     llvm-profdata: Avoid undefined behaviour when reading raw profiles<br>
>> ><br>
>> >     The raw profiles that are generated in compiler-rt always add padding<br>
>> >     so that each profile is aligned, so we can simply treat files that<br>
>> >     don't have this property as malformed.<br>
>> ><br>
>> > Any chance of changing this to not rely on UB (this code looks like it's<br>
>> > violating C++ aliasing rules pretty consistently) and instead using memcpy?<br>
>><br>
>> It's always casting from char *, which IIUC doesn't break aliasing<br>
>> rules, so I *think* that this isn't relying on UB.<br>
>><br>
> [+Richard for some language lawyering]<br>
><br>
> I believe the rules are:<br>
><br>
> You can take a pointer to any entity, cast it to a char* then back, and continue using it as the original type. But this only works if the pointer was originally a pointer to that type you're dereferencing by, which isn't the case here.<br>
><br>
> You can take a pointer to T (where T is a standard layout(?)), cast to pointer to char, read the bytes of the object then write them back into some other object (via a char* that actually points to a T - derived the same way as the original) you can do that safely.<br>
><br>
> But none of this allows taking a char* that wasn't derived from a T*, casting it to a T* and reading.<br>
><br>
> But this is just my high-level understanding, I don't actually know where the words are in the standard to support this position.<br>
<br>
</span>C++11 has them in the bullet point list in section 3.10.<br></blockquote><div><br></div><div>Ah, thanks 3.10p10 specifically. Huh, didn't know you could read an unsigned int as an int, for example... that's a bit weird, but OK.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sorry about this, looks like I missed that subtlety :/.<br>
<span class=""><br>
> Hoping Richard can fill us in/confirm/deny and/or I can go hunting.<br>
><br>
> - David<br>
><br>
><br>
> Assuming I'm right about that, the current design avoids unnecessarily<br>
> copying from the file to an auxiliary structure just to read the data<br>
> and throw it away.<br>
<br>
</span>I think the optimizer will see through the `memcpy`s anyway, so this<br>
probably isn't a big deal.<br></blockquote><div><br></div><div>That's certainly the goal - file bugs whenever this doesn't work. </div></div><br></div></div>