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

Mikael Vidstedt mikael.vidstedt at
Fri Jan 11 17:53:29 PST 2013


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?


>> -- 
>> 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
>>> <>
>>> Bug link at
>>> Thank you,
>>> Harold

More information about the hotspot-runtime-dev mailing list