Re: [PATCH] Avoid truncating to 'long' in ALIGN() macro

[Al Viro <viro@ftp.linux.org.uk>]

On Sun, Nov 26, 2006 at 02:20:10PM -0800, Linus Torvalds wrote:
> So arguably, the result is _more_ like a normal C operation this way. 
> Type-wise, the "ALIGN()" macro acts like any other C operation (ie if you 
> feed it an "unsigned char", the end result is an "int" due to the normal C 
> type widening that happens for all C operations).
> 
> But I don't care horribly much. Al may have some other reasons to _not_ 
> want the normal C type expansion to happen (ie maybe he does something 
> unnatural with sparse ;)

Type expansion will happen as soon as you do any arithmetics (or passing
as argument) anyway.

It's actually more of "typeof() has interesting interactions with
other gccisms" kind of thing and general dislike of using that beast
more than absolutely necessary.

Not the #1 on my list of the worst gccisms we are using (that would be
({...}) with its insane semantics and interesting ways to get gcc puke
its guts out), but still pretty high there...

ObFun: what's the type of ({struct {int x,y;} a = {1,2}; a;}) and
how comes that we can say
	({struct {int x,y;} a = {1,2}; a;}).y
and get gcc eat it up and evaluate that to 2?  Note that we are doing
a very obvious violation of scope rules - WTF _is_ .y in scope where
we have no visible declaration of any structure with field that would
have such name?

IOW, gcc allows type to leak out of scope it's been defined in (and
typeof adds even more fun to the picture).  It not only goes against
a _lot_ in C, it's actually not thought through by gcc folks.  Just
try to mix that with variable-length arrays and watch it blow up
in interesting ways...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/