RFR(XXS): 7133111: libsaproc debug print should be printed as unsigned long to fit large numbers on 64bit platform
Kelly O'Hair
kelly.ohair at oracle.com
Thu Apr 5 12:46:36 PDT 2012
I vaguely recall sizeof(long) being 4 on Windows X64.
Use of the type "long" always raises red flags for me, including the printf options related to the long types.
Just a warning.... be safe out there... ;^)
-kto
On Apr 5, 2012, at 11:01 AM, Dmitry Samersoff wrote:
> On 2012-04-05 20:32, Staffan Larsen wrote:
>> Isn't the problem with casting to (unsigned long) that this only a 32 bit type and size_t can be 64?
>
> Long scales with architecture as opposite to int.
>
> printf("%d,%d,%d\n", sizeof(size_t), sizeof(long), sizeof(int) );
>
> mircat(FreeBSD 64bit):dms#./test
> 8,8,4
>
> -Dmitry
>
>
>
>>
>> /Staffan
>>
>> On 5 apr 2012, at 16:54, Dmitry Samersoff wrote:
>>
>>> Staffan,
>>>
>>> OK for me.
>>>
>>> But I would prefer to handle it standard rather than Linux specific way
>>> to benefit other possible ports.
>>>
>>> i.e. %ld and (unsigned long) ph->core->map_array[j]->memsz
>>>
>>> -Dmitry
>>>
>>> On 2012-04-05 16:25, Staffan Larsen wrote:
>>>> Please review the following one-character fix to a printf format string. A 'z' is added to the printout of a size_t field.
>>>>
>>>> Thanks,
>>>> /Staffan
>>>>
>>>>
>>>> diff --git a/agent/src/os/linux/ps_core.c b/agent/src/os/linux/ps_core.c
>>>> --- a/agent/src/os/linux/ps_core.c
>>>> +++ b/agent/src/os/linux/ps_core.c
>>>> @@ -440,7 +440,7 @@
>>>> int j = 0;
>>>> print_debug("---- sorted virtual address map ----\n");
>>>> for (j = 0; j< ph->core->num_maps; j++) {
>>>> - print_debug("base = 0x%lx\tsize = %d\n", ph->core->map_array[j]->vaddr,
>>>> + print_debug("base = 0x%lx\tsize = %zd\n", ph->core->map_array[j]->vaddr,
>>>> ph->core->map_array[j]->memsz);
>>>> }
>>>> }
>>>
>>>
>>> --
>>> Dmitry Samersoff
>>> Java Hotspot development team, SPB04
>>> * There will come soft rains ...
>>
>
>
> --
> Dmitry Samersoff
> Java Hotspot development team, SPB04
> * There will come soft rains ...
More information about the serviceability-dev
mailing list