On Thu, 5 Jul 2007, Al Viro wrote:
>
> I.e. you get per-attribute rules (fsckloads of them) and no way to tell
> what do the attributes apply to unless you know the rules for given attribute.
It basically boils down to "__attribute__((x))" is basically a _single_
keyword.
There is no "__attribute__" on its own, or "x" on its own. The two do not
make sense separately.
And that's the _accurate_ way of seeing attribute. Seeing it as a "type
attribute" is actively wrong, and that kind of thinking just leads you
down the wrong path (not just with qualifiers, but with __attribute__ as
done by gcc itself, where it's used for more than type attributes).
> I just don't like having no relationship between the syntax and operations
> on types, that's all.
You seem to think that "__attribute__" has some meaning of its own.
Not true.
Gcc already has things like
__attribute__((extended))
which acts not on types or variables, but on expressions and statements.
And it does not *make*sense* to think of that as just another "attribute".
It is *not* about the same kind of attributes as the type attributes at
all! If you think it is, you're thinking about it wrong. It's a totally
different kind of thing.
So instead of thinking about "__attribute__" as having some stand-alone
semantic meaning (it does *not*), think of it the way I do: the
"__attribute__" part is just an escape sequence into an extended parsing
thing, and "__attribute__((extended))" is really just another way to give
a way to say the _extended_ thing, without having to make it a keyword,
with all that implies.
In other words, I think your "__qualifier__" idea is fundamentally wrong,
because it misses the real _point_ of "attribute()".
The real point of "__attribute__" is that it's mis-named. But that does
not mean that it should be named "__qualifier__", because that just
re-inforces the initial mistake. Instead, it probably _should_ have been
named "__extension__", or something like that (or maybe "__escape__" or
"__magic_keyword__").
That ends up explaining all the gcc semantics. Because "__attribute__" as
gcc uses it really isn't about attributes per se, it's about extensions to
C semantics, in a way that doesn't violate the C rules that much, and in a
way that doesn't introduce infinite numbers of special identifiers in the
same global name-space.
So yes, I'd be ok with renaming it, and I don't think "__attribute__" is a
wonderful name, but we named it for gcc compatibility, so we're kind of
stuck with the name. But that doesn't mean that we have to be stuck with
thinking about it as a "symbol node attribute", because it really isn't,
and has never been that, even in gcc.
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]
