You're correct Kelly. In the general case one can't trust the size of
long to be as wide as size_t. For that reason the use case for long has
always been somewhat of a mystery to me, especially in portable code.
/Mikael
On 2012-04-05 12:46, Kelly O'Hair wrote:
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 ...
