On Tue, May 22, 2007 at 02:40:11PM -0700, Josh Triplett wrote:
> > What's going on here is pretty simple: there are two degenerate cases of
> > conditional operator: pointer vs. null pointer constant and pointer vs.
> > possibly qualified pointer to void. Look at these cases:
> > n ? p : NULL => should be the same type as p
> > n ? p : v => clearly const void * - pointer to void with union of
> > qualifiers; in this case we obviously lose any information about the type
> > of object being pointed to.
>
> I didn't actually know about the special case for a null pointer constant.
Rationale is pretty simple: normally if you have void * in the mix, you
_can't_ expect more type information from the result; i.e. you are not
promised that result of ?: will point to int. However, null pointer constant
is a chameleon - it accepts whatever pointer type you might need in given
context. So in that case you do _not_ lose the type information.
> In particular:
> > n ? p : (void *)NULL int * => void *
> Shouldn't this have type int * just like n ? p : NULL ?
No. It's "void * and I _mean_ it". Well... actually (void *)(void *)0 if
you want to be 100% portable and protect yourself against cretinous systems
that define NULL to 0.
Again, null pointer constant is not the same thing as null pointer to void.
BTW, there's another painful area: what do we do to somebody who uses
(void *)(69 + 1 - 70) as null pointer constant? Currenly sparse doesn't
recognize it as such; C standard does. IMO the right thing to do is
to add a flag that would switch to full-blown standard rules in that area
("integer constant expression returning 0" instead of basically "0 in some
layers of ()") and flame to the crisp any wanker caught at actually doing
that. Any suggestions re sufficiently violent warning messages?
-
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
