<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Nov 13, 2012 at 2:27 PM, Eli Friedman <span dir="ltr"><<a href="mailto:eli.friedman@gmail.com" target="_blank">eli.friedman@gmail.com</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 Tue, Nov 13, 2012 at 2:09 PM, Ulrich Weigand<br>
<<a href="mailto:Ulrich.Weigand@de.ibm.com">Ulrich.Weigand@de.ibm.com</a>> wrote:<br>
><br>
> Hello,<br>
><br>
> this change (part of r167853):<br>
><br>
> +    uint32_t *offsetaddr =<br>
> +             (uint32_t *)(reinterpret_cast<const support::ulittle32_t*><br>
> (offsets)<br>
> +                          + (offsetindex - 1));<br>
> +    assert((const char *)offsetaddr <<br>
> +           Parent->SymbolTable->getBuffer()->getBufferEnd());<br>
> +    offset = *(offsetaddr);<br>
><br>
> causes crashes when llvm-nm is compiled on a big-endian host; note how the<br>
> "support::ulittle32_t" pointer is cast back right away to a plain uint32_t<br>
> pointer, which gets dereferenced using the host endianness.<br>
><br>
> The attached patch fixes this (fixing the Object/coff-archive.test test<br>
> case on PowerPC), and removes a const-violation warning as well.<br>
><br>
> OK to commit?<br>
<br>
</div></div>Not really your fault, but am I the only one who finds it a little<br>
scary we're adding an arbitrary value to a pointer and expecting it to<br>
point at valid memory?<br></blockquote><div><br></div><div>Not really, no, but at least some of how this stuff is written works on magic constants anyhow. Might be nice to codify a lot of these as functions/defines/something.</div>
<div><br></div><div>-eric</div></div></div>