Al Viro wrote:
> 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.
Makes sense, except that in C you can assign a void pointer to an arbitrary *
without a warning, so why can't conditional expressions do the equivalent?
>> 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.
I see. I find it very strange that (void *)0 and (void *)(void *)0 have
different behavior. I also find it strange that conditional expressions can't
convert void * to an arbitrary pointer as assignment can.
> 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?
I didn't know that the C standard actually *required* constant folding.
Interesting. Would it add excessively to compilation time to apply the usual
Sparse constant folding here? If so, and if you really think this case
matters, let's have an option to turn on this constant folding, and warn
whenever we see it. I'll let you come up with the wording; flame away. :)
Anyone expecting that behavior has some serious dain-bramage. If constant
folding *wouldn't* add excessively to the compilation time, go ahead and
handle the insanity the standard way by default, but still warn for the insane
case.
- Josh Triplett
Attachment:
signature.asc
Description: OpenPGP digital signature
