linux-sparse.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Al Viro <viro@ftp.linux.org.uk>
To: linux-sparse@vger.kernel.org
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org
Subject: [RFC] bloody mess with __attribute__() syntax
Date: Thu, 5 Jul 2007 10:35:28 +0100	[thread overview]
Message-ID: <20070705093528.GK21478@ftp.linux.org.uk> (raw)

	We have a fun problem and for a change it's not sparse fault.
It's gcc folks' one.  Basically, __attribute__((...)) behaves in
an idiotic way and it's an intentional (and documented) behaviour.
In declaration of form
	T __attribute__((foo)) **v;
the attribute applies to v, not to **v.  IOW, in that position it
behaves (regardless of the nature of attribute) as storage class,
not as a qualifier.  Even if the same attribute can be used in
	T * __attribute__((foo)) *v;
where it will apply to *v.  Intended way to have it apply to **v is
	T (__attribute__((foo)) **v);

To put it mildly, that blows.  Note that qualifiers can *not* behave
that way - direct declarator can not expand to (<qualifier> <something>).
I.e. if you replace __attribute__((foo)) with qualifier in the
above, you'll get invalid syntax.

Now, that idiocy would be none of our concern, if not for the fact
that noderef and address_space() are definitely supposed to imitate
qualifiers.  If anybody seriously suggests switching to syntax
like
	int (__user *p);
all over the place, well...

Note that gcc rules for __attribute__() (and that's the only source
of rules we _have_ for the damn thing) clearly say that
	int __user *p;
is the same thing as
	int *__user p;

Now, we could declare gcc people responsible for that turd rejects
of Vogon Construction Fleet and handle the damn thing sanely.
The first part is clearly the right thing to do, but the second one...
Can't do without breaking gccisms using __attribute__.  E.g.
	int (__attribute__((mode(__pointer__))) *p);
is a gcc way to say "pointer to integer type equivalent to intptr_t" and
	int __attribute__((mode(__pointer__))) *p;
is exactly the same thing as
	int *p;
since the damn attribute applies to the entire type here (and is obviously
a no-op).

Frankly, I would rather add a new primitive (__qualifier__) mirroring the
__attribute__, but acting like real qualifiers do.  And switched the
noderef et.al. to it.  The only real alternative is to have __attribute__
behaviour dependent on its guts and that's not feasible - remember that
there can be more than one attribute in the list insider the damn thing.
Besides, it's bloody disgusting.

And yes, I realize that it's an incompatible change, i.e. not a step
to be taken lightly.  Better ways out of that mess are more than
welcome; I don't see any ;-/

             reply	other threads:[~2007-07-05  9:35 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-05  9:35 Al Viro [this message]
2007-07-05 12:03 ` [RFC] bloody mess with __attribute__() syntax Arnd Bergmann
     [not found]   ` <OFC2AA6078.1DF7BE7E-ON4225730F.0044BE34-4225730F.0046B6F1@de.ibm.com>
2007-07-05 16:27     ` Al Viro
2007-07-13  9:04       ` Al Viro
2007-07-05 15:36 ` Josh Triplett
2007-07-05 16:43   ` Al Viro
2007-07-05 18:50     ` Josh Triplett
2007-07-05 19:13       ` Al Viro
2007-07-05 19:35         ` Josh Triplett
2007-07-05 20:08           ` Al Viro
2007-07-05 20:56             ` Linus Torvalds
2007-07-06  3:26               ` Al Viro
2007-07-05 21:09             ` Josh Triplett
2007-07-06  7:48       ` Al Viro
2007-07-06  8:33         ` Josh Triplett
2007-07-06 15:52           ` Al Viro
2007-07-06 19:29             ` Josh Triplett
2007-07-07  2:11               ` Al Viro
2007-07-07  2:28                 ` Josh Triplett
2007-07-08 21:50                   ` Al Viro
2007-07-07  2:30                 ` Al Viro
2007-07-07  2:55                   ` Josh Triplett
2007-07-08 21:52                     ` Al Viro
2007-07-05 16:41 ` Linus Torvalds
2007-07-05 16:53   ` Al Viro
2007-07-05 17:02     ` Chris Lattner
2007-07-05 17:09   ` Al Viro
2007-07-05 17:26     ` Linus Torvalds
2007-07-05 18:07       ` Al Viro
2007-07-05 18:56         ` Linus Torvalds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070705093528.GK21478@ftp.linux.org.uk \
    --to=viro@ftp.linux.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sparse@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).