Hi Jakub,
On 1/8/22 11:30, Jakub Wilk wrote:
For the record, this is what you get when you compile the original code
on a 64-bit architecture:
$ gcc -Wall -pthread malloc_info-example.c
malloc_info-example.c: In function 'thread_func':
malloc_info-example.c:16:14: warning: cast from pointer to integer
of different size [-Wpointer-to-int-cast]
16 | int tn = (int) arg;
| ^
malloc_info-example.c: In function 'main':
malloc_info-example.c:57:32: warning: cast to pointer from integer
of different size [-Wint-to-pointer-cast]
57 | (void *) tn);
| ^
* Alejandro Colomar <alx.manpages@xxxxxxxxx>, 2022-01-08, 03:25:
On 1/7/22 17:46, Stephen Kitt wrote:
int isn't large enough to store pointers on all platforms, use
intptr_t instead.
Well, since the pointer came from a previous 'int', there should be no
problem. But since the C language (or even POSIX) is very permissive
about what a conforming implementation can do with pointers, and it
only guarantees conversions to/from [u]intptr_t, I'd take this patch
for correctness. However...
The standards guarantee that void* → intptr_t → void* round-trips, but
that's not what this code does.
The example converts int → void* → int. Changing int to intptr_t makes
the compiler warnings go away, but I don't think it improves correctness
in any way.
Hmm, you're right.
Semantically, 'int' feels better, since the original data is 'int', not
a pointer. So a cast here to pass through the pointer API would be ok.
I don't think there's any arch where it would be a problem.
I'll keep the program as is.
Thanks,
Alex
--
Alejandro Colomar
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/
