Re: [PATCH 9/9] malloc_info.3: Use intptr_t to store pointers

["Alejandro Colomar (man-pages)" <alx.manpages@gmail.com>]

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@gmail.com>, 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/