This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Ping: Ping: [Patch][RFA] Warn if pointer is initialized to 'false'


On Mon, Feb 1, 2010 at 3:01 PM, Simon Baldwin <simonb@google.com> wrote:
> On 1 February 2010 01:10, Dave Korn <dave.korn.cygwin@googlemail.com> wrote:
>> On 01/02/2010 00:28, Mark Mitchell wrote:
>>>
>>> We're talking about whether to issue a pedwarn or a warning, not whether
>>> to warn at all. ?We certainly want to warn.
>>
>> ?Beg pardon, I must have misread the thread.
>
> I think I'm misreading this review in the same way as well, now. ?The
> first response mentions OK, but then questions the change to call.c,
> which is after all the only meaningful part of the patch.
>
> false is a valid 'null pointer constant'. ?It's just a very odd one.
> It's currently a warning if used as the argument to a function that
> takes a pointer, but not if directly assigned to a pointer variable,
> which seems strange.
>
> The patch introduces a warning for the latter also, since it seems
> likely that it's a bug-in-waiting. ?However, I ?know there are also
> some intentional uses of false as a function argument for a function
> taking a pointer (Boost, for example, relies on this). ?Perhaps some
> subtlety along these lines is why direct assignment is not already a
> warning. ?It's also produced only if -Wconversion, something not added
> with -Wall -Wextra.
>
> Here's a more full example of how the current gcc behaves:
>
> ?// gcc -Wconversion ...
> ?void *f(void *p) {return p;}
> ?void *a = true; ? ? ?// error: cannot convert 'bool' to 'void*' ...
> ?void *b = f(false); ?// warning: converting 'false' to pointer type for ...
> ?void *c = false; ? ? // without the patch, an eerie silence; with, a warning
>
> It does seem odd that at present false is warned about if used as an
> argument to a function that takes a pointer, but not if directly
> assigned to a pointer variable.
>
> Anyway, I'm not wedded to this patch. ?If the risks outweigh the
> advantage I'm happy to drop it.

Either way you go, please defer this to GCC 4.6 - we're late with 4.5
and risking possibly a lot of late fallout from user code.

Thanks,
Richard.

> --
> Google UK Limited | Registered Office: Belgrave House, 76 Buckingham
> Palace Road, London SW1W 9TQ | Registered in England Number: 3977902
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]