<div dir="ltr">The problem of the code is that assigned a size_t value to a uintX_t variable, assuming that they are the same type. Use size_t consistently when you represent an offset of an array on the *host* machine. This is not a compromise or any artificial capping. You are confusing uintX_t, which is size_t of the *target* machine, with size_t of the host machine.<div><br></div><div>(Or, are you suggesting that we should be able to cross-link >4GB executables on a 32-bit computer?)</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 29, 2015 at 8:28 AM, George Rimar <span dir="ltr"><<a href="mailto:grimar@accesssoftek.com" target="_blank">grimar@accesssoftek.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">grimar added a comment.<br>
<br>
Idea of virtual space is clear for me. I still can imagine implementations of StringTableBuilder where size_t will not be enough (like keeping strings in multiple files), but that is not real case, I agree.<br>
<br>
One last though:<br>
When using size_t instead of strict type like uint_x we have different behavior of linker depending on environment. And that can cause the fails of tests like we had. Using of strict types can help to avoid that. So I mean even uint32_t here can be better that size_t since behavior between 32x/64x configurations will be consistent. But at the same time I dont see the solid reasons to artifically cap to 32 bits variable. That returns to idea to have template size type for StringTableBuilder, because truncation of 64 bits size_t to something like uint32_t is still bad to have. Or If StringTableBuilder really does not need that (I would agree now) then using of uint_x (assuming its size >= size_t) is still looks like a solution for behavior consistency.<br>
<br>
<br>
<a href="http://reviews.llvm.org/D14171" rel="noreferrer" target="_blank">http://reviews.llvm.org/D14171</a><br>
<br>
<br>
<br>
</blockquote></div><br></div>