<p dir="ltr">Nick,</p>
<p dir="ltr">Is it okay to land this change with a FIXME to the MachODefinedAtom and a FIXME to see if we can avoid copying the data?</p>
<div class="gmail_quote">On 3 Jan 2014 03:14, "Nick Kledzik" <<a href="mailto:kledzik@apple.com">kledzik@apple.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><br><div><div>On Jan 2, 2014, at 5:48 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr">
<div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 2, 2014 at 8:07 PM, Nick Kledzik <span dir="ltr"><<a href="mailto:kledzik@apple.com" target="_blank">kledzik@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="overflow:hidden">On <span>Jan 2, 2014</span>, at <span>4:41 PM</span>, Joey Gouly <<a href="mailto:joey.gouly@gmail.com" target="_blank">joey.gouly@gmail.com</a>> wrote:\<br>
<div>><br>
><br>
> ================<br>
> Comment at: lib/ReaderWriter/MachO/MachONormalizedFileYAML.cpp:282<br>
> @@ -280,1 +281,3 @@<br>
> + io, sect.content);<br>
> + io.mapOptional("content", content->normalizedContent);<br>
> io.mapOptional("relocations", sect.relocations);<br>
> ----------------<br>
> <a href="mailto:kledzik@apple.com" target="_blank">kledzik@apple.com</a> wrote:<br>
>> I think you can just cast the address of sect.content to be of type ContentBytes and it should all just work with no need for NormalizedContent.<br>
> mapOptional wants a reference to the content, so I cant use the address of content, and as far as I can tell, I can't change the type of a reference.<br>
><br>
> Unless I'm mistaken, I can't do this without copying.<br>
<br>
</div>This works for me:<br>
<br>
Index: lib/ReaderWriter/MachO/MachONormalizedFileYAML.cpp<br>
===================================================================<br>
--- lib/ReaderWriter/MachO/MachONormalizedFileYAML.cpp (revision 198349)<br>
+++ lib/ReaderWriter/MachO/MachONormalizedFileYAML.cpp (working copy)<br>
@@ -276,7 +276,8 @@<br>
io.mapOptional("attributes", sect.attributes);<br>
io.mapOptional("alignment", sect.alignment, 0U);<br>
io.mapRequired("address", sect.address);<br>
- io.mapOptional("content", sect.content);<br>
+ ContentBytes &cont = *reinterpret_cast<ContentBytes*>(§.content);</div></blockquote></div><br>Using the vector after this is totally undefined behavior. You can't just cast vector<T>* to vector<U>* and then access the vector with that pointer when T != U. It doesn't matter what the layout or size of T and U are, the vector types are completely different and might have nothing to do with each other.</div>
</div>
</blockquote></div>Are you saying that the compiler can layout the vector<T> object differently than a vector<U> object, or that that actual array buffer can be laid out differently, or that the compiler can do something wild in the cast because it thinks that types are incompatible?<div>
<br></div><div>How can two compilers generate binary compatible code if the the layout of classes is not deterministic? If the layout is deterministic, why would vector<T> and vector<U> be different?</div><div>
<br></div><div>-Nick</div><div><br></div></div>
<br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div>