[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
signature.asc
Description: OpenPGP digital signature