RFR(L): 8037816 : Fix for 8036122 breaks build with Xcode5/clang
david.r.chase at oracle.com
Mon Apr 28 11:57:55 UTC 2014
On 2014-04-28, at 3:07 AM, David Holmes <david.holmes at oracle.com> wrote:
> On 25/04/2014 10:10 PM, David Chase wrote:
>> On 2014-04-25, at 1:29 AM, Stefan Karlsson <stefan.karlsson at oracle.com> wrote:
>>> Hi David,
>>>> Among the changes/observations:
>>>> int64_t and jlong are NOT NOT NOT the same type on all platforms.
>>> Could you clarify this? To me they both look like 64 bit signed integers. What am I missing?
>> On at least one 64-bit platform (I think at least XCode 4.6.3 / gcc 4.2 on Mountain Lion) one
>> of the two is defined to be "long" and the other "long long". Even though both of those are
>> 64 bits, gcc "knows" that there are platforms where long is only 32 bits, and hence this could
>> be a problem when you recompile on different platform.
> That doesn't make sense to me. gcc should be looking at the current definitions of those types in the current build, not considering some absolute truth as to what these types might be across different platforms.
I am just the messenger -- if we intend to enable format warnings, and to mark our own printf-ish methods appropriately, and warnings are errors, and we use gcc, then we have to put up with gcc's silliness. The automated format/arg warnings (i.e., the warnings in this extremely picky category, not literal/empty/length) did catch one bug that Vladimir K concurrently repaired (printing int as %s, not so good) and found another where we printed a default case constant as a %f, plus it has tagged numerous actual integer width mismatches (that might or might not bite us in some future port, it has a lot to do with how parameters are passed and endianness).
How do you like it otherwise? I'm itching to get reviews and get this thing out of my hair.
More information about the hotspot-dev