On Wed, 27 Jun 2007, Neil Booth wrote:
>
> Here are three independently invalid non-ICEs that sparse doesn't
> diagnose.
>
> extern int f(void);
> enum { cast_to_ptr = (int) (void *) 0 };
> enum { cast_to_float = (int) (double) 1 };
Those two *really* shouldn't fail. I don't care if the C standard says so,
that is *fine*.
In particular, "offsetof()" should be portably able to basically be the
standard #define, which involves an integer cast from a constant pointer.
That had *better* be a valid constant integer expression, because it's
very useful.
And I think standards can go screw themselves, and you can make it an
error with some "--standard-pedantic" switch or similar.
Standards are just random pieces of paper, for crying out loud! They have
zero relevance in the end.
> enum { fncall = 0 ? f(): 3 };
Again, I think that's a deficiency of a standard that tries to be
acceptable to everybody rather than about a "really good language".
So I personally think we should allow it too if at all possible, and
again, use some "--standard-pedantic" to flag it as an error.
Why? Because things like that may not look sensible when written out, but
they are often _very_ sensible when they are the result of a macro that
does some error checking or other thing.
The classic example of this is "__builtin_constant_p()". It is a *great*
way to make a macro that does different things depending on whether
something is a compile-time constant or not, and no, it's not standard,
but dang, it's so useful that a standard that doesn't allow sane use of it
is basically bogus.
So look at the "ntohl()" kind of thing, and realize that it's just "Good
Practice(tm)" to be able to make a ntohl() macro that can be used for
initializers, including very much enum initializers. Ie
enum { defaultport = htons(9418) };
is actually nice code for something like the kernel, but it turns out that
in order to make this work, you have to do it as
#define htons(x) (__builtin_constant_p(x) ? constant_htons(x) : __htons(x))
and that in turn generates *exactly* the kind of thing you talk of above.
And when you give _your_ example, it looks insane. When I give _my_
example, it generates exactly the same thing, but suddenly it has a great
reason for doing so, and it's no longer insane.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
