Request for review: 7102489: RFE: cleanup jlong typedef on __APPLE__ and _LP64 systems

[Mikael Vidstedt]

Below

On 2013-01-11 07:02, harold seigel wrote:
> Hi David,
>
> Thanks for your comments.  My replies are interspersed.
>
>>
>> src/share/vm/utilities/globalDefinitions_gcc.hpp
>>
>> Why do we need a special case for Apple? AFAIK for ILP32 and LP64 
>> "long long" is always 64-bits so %lld should always be valid.
>>
> This answer is similar to the one I sent to Vladimir.  We need a 
> special case for Apple because its compiler is picky about format 
> specifiers.  It will issue a warning for values of type long that have 
> format specifiers of %lld.  For example, on Mac OS, this program gets 
> a compilation warning at line 6, but not line 5.
>
> $ gcc lld.cpp
> lld.cpp: In function int main(int, char**):
> lld.cpp:6: warning: format %lld expects type long long int, but 
> argument 2 has type long int
>
> $ cat lld.cpp
> #include <stdio.h>
>
> int main(int argc, char * argv[]) {
>   long val = 5;
>   printf("val: %ld\n", val);
>   printf("val: %lld\n", val); <--- line 6
>   return 0;
> }

I'm not I understand what you're trying to say with this. Here's my 
naive thinking:

jlong needs to be typedef:ed to something that is a signed 64 bit wide 
type. int64_t is per definition exactly that, so I'd suggest either 
using int64_t to define jlong (typedef int64_t jlong; ) or look at how 
int64_t is defined and define jlong in the same way. The format for 
printing jlong would then be the same as printing an int64_t, which is 
what INT64_FORMAT is supposed to do. Introducing the new format could 
still make sense for clarity, but I don't think it is strictly needed?

Am I missing something?

Cheers,
Mikael

>> -- 
>>
>> src/share/vm/utilities/ostream.cpp
>>
>> I think the N.B comments could be deleted.
>
> I agree.  I'll delete those comments.
>
>>
>> -- 
>>
>> Thanks,
>> David
>>
>>
>>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_7102489/
>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_7102489/>
>>> Bug link at http://bugs.sun.com/view_bug.do?bug_id=7102489
>>>
>>> Thank you,
>>> Harold