[PATCH] D14171: [ELF2] merge-string.s test fixed for win32 configuraton.

[Rui Ueyama via llvm-commits]

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.

(Or, are you suggesting that we should be able to cross-link >4GB
executables on a 32-bit computer?)

On Thu, Oct 29, 2015 at 8:28 AM, George Rimar <grimar at accesssoftek.com>
wrote:

> grimar added a comment.
>
> 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.
>
> One last though:
> 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.
>
>
> http://reviews.llvm.org/D14171
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151029/b2dd1317/attachment.html>