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

[Simon Baldwin <simonb at google dot com>]

On 1 February 2010 16:59, Richard Guenther <richard.guenther@gmail.com> wrote:
>
> 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.

Noted, thanks.

In fact I already have a queue of things like this I've been sitting
on since Nov last year that are okayed but which I've put off
committing awaiting the 4.6 stage 1, because none remotely qualifies
as a bug fix or regression.  This is just one more to add to it.

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