[prev in list] [next in list] [prev in thread] [next in thread] 

List:       coreutils
Subject:    Re: [PATCH] maint: avoid clang -Wint-to-pointer-cast warning
From:       Eric Blake <eblake () redhat ! com>
Date:       2014-07-14 15:20:57
Message-ID: 53C3F559.4080701 () redhat ! com
[Download RAW message or body]


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


["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]