coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] maint: avoid clang -Wint-to-pointer-cast warning


From: Eric Blake
Subject: Re: [PATCH] maint: avoid clang -Wint-to-pointer-cast warning
Date: Mon, 14 Jul 2014 09:20:57 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

On 07/13/2014 06:59 PM, Bob Proulx wrote:
> Pádraig Brady wrote:
>> Subject: Re: [PATCH] maint: avoid clang -Wint-to-pointer-cast warning
> 
> What was the text of the original warning?  I think that would be
> interesting to review.  I think it would provide an additional clue.
> 
>> * src/chroot.c: Explicitly cast int to pointer type.
> 
>> -          g = (struct group *)! NULL;
>> +          g = (struct group *) (intptr_t) ! NULL;
> 
> I would like to look at this cast to a cast again.  It already had a
> cast before.  I think adding an additional cast is one too many.  I am
> surprised that it isn't still tripping over a warning.  And I think
> later that the multiple cast might itself be the source of yet a
> future warning.

Why not just write:

g = (struct group *) 1;


> 
> Note that in C the NULL macro is effectively 0.  In C++ it is
> different but sticking to C only for now could say that is 0.  So
> therefore the "g = ! 0" which is basically 0xFFFFFFFF the all ones
> value.  And so we see the problem of the pointer casting to make that
> happy.  But it does not feel good to me.

No, ! NULL is _always_ 1, in C and C++.  Using the ! operator on any
pointer coerces the operation into boolean context, which can only give
0 or 1, not 0xffffffff.

> 
> And sorry but that is all of the time I have at this moment.  I hope
> to look at it more again later.  And chown too to see how it handles it.

I agree with this worry about revisiting the code clarity in the first
place. I've seen uses of double casting through an intermediate
(intptr_t) when treating an int as a pointer (most often, when passing
an integer to a void* opaque parameter of a callback, rather than
passing an address to a pointer to integer).  But it is always odd
looking, so if it can be avoided by a clearer code construction, I'm all
for that.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]