On 12/ 2/16 12:00 PM, Josh Stone wrote:
I'd favor uintptr_t to keep better compatibility with current elfutils.
That's not perfect either, since glibc uses "unsigned int" on 32-bit
platforms, so that could still cause warnings for things that strictly
expect long, like printf "%lx". But directly printing a newehdr return
value (without saving it somewhere) is a weird thing to do, so I think
we can dismiss that case, at least. Off the top of my head, I can't
think of anything else that's so strict about long vs. int.
Another option is to make the change conditional on __LP64__, so
existing platforms are totally unaffected. I'd still lean toward
uintptr_t for the new case, so existing libelf code can port easily.
In a 32-bit environment, int, long, and (void *) are all a 32-bit
integer at the machine level. That's true for any unix I know about
(including Linux) and also for Win32 and Win64 (and I presume that
no one cares about Win16). As a result, printf "%x" and "%lx"
are equivalent. The compiler might warn, but the code it generates
would be correct, and so, the noise is a good thing --- it will
encourage you to go change your printf to use "%p", but if you
ignore it, nothing bad will occur as a result.
I expect very little compiler noise for C programs, because in C,
'void *' is very promiscuous, and adapts without complaint to any
assignment. C++ might be a bigger issue, and I guess the question there
is: How much C++ code is out there using these, and why would it not be
better for that code to just get fixed? Even in C++, existing old C++
binaries would continue to run without issue.
Although uintptr_t would work, it seems unnecessary. Note that freebsd
already uses 'void *', and surely they build most of the same ELF-related
FOSS code that we might be concerned about, so I think that the libelf
code already has ported easily. As such, and given that 'void *' is the
common C idiom for this sort of use, I think it would make sense to
use it.
We should all do the experiment and report back.
- Ali
_______________________________________________
elfutils-devel mailing list -- elfutils-devel@lists.fedorahosted.org
To unsubscribe send an email to elfutils-devel-le...@lists.fedorahosted.org
