public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ftp.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-sparse@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC] bloody mess with __attribute__() syntax
Date: Thu, 5 Jul 2007 19:07:42 +0100	[thread overview]
Message-ID: <20070705180742.GP21478@ftp.linux.org.uk> (raw)
In-Reply-To: <alpine.LFD.0.98.0707051014380.9434@woody.linux-foundation.org>

On Thu, Jul 05, 2007 at 10:26:40AM -0700, Linus Torvalds wrote:
> And I'm just saying that:
>  (a) having two different magic keywords is silly and stupid, since:
>  (b) We already have *one* magic keyword that can (and has to) look at its 
>      subwords, and those sub-words have the capability to tell which of 
>      the two cases we have (by just using name-space lookups)

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.

> See? THAT is what I'm saying. There's no reason to change existing syntax, 
> and in fact it is just _bad_ to change existing syntax, because it doesn't 
> actually buy us anything, because we already have the capability to parse 
> things in different contexts, and in fact allowing things to be parsed at 
> the same _time_ in the different contexts.

Oh, I understand what you are proposing (hell, I've mentioned that variant
in the first posting).  The trouble is not with being able to implement it.
I just don't like having no relationship between the syntax and operations
on types, that's all.  gcc variant, nasty as it is for our needs, at least
has that consistent.  IOW, you can get from declaration to type structure
without knowing what each attribute does.  Seeing that gcc rules are
weird enough to be confusing, at least having that weirdness clearly
indicated by __attribute__() instead of recalling which attribute is gcc-like
and which is not...

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

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-05  9:35 [RFC] bloody mess with __attribute__() syntax Al Viro
2007-07-05 12:03 ` Arnd Bergmann
     [not found]   ` <OFC2AA6078.1DF7BE7E-ON4225730F.0044BE34-4225730F.0046B6F1@de.ibm.com>
2007-07-05 16:27     ` 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-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 [this message]
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=20070705180742.GP21478@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