All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Christopher Li <sparse@chrisli.org>
Cc: Al Viro <viro@ftp.linux.org.uk>, linux-sparse@vger.kernel.org
Subject: Re: [patches] more declarations fixes
Date: Tue, 10 Mar 2009 22:42:14 +0000	[thread overview]
Message-ID: <20090310224214.GU28946@ZenIV.linux.org.uk> (raw)
In-Reply-To: <70318cbf0903101427y238844d9xfa19baa8c637437e@mail.gmail.com>

On Tue, Mar 10, 2009 at 02:27:26PM -0700, Christopher Li wrote:
> On Mon, Mar 9, 2009 at 12:10 AM, Al Viro <viro@ftp.linux.org.uk> wrote:
> >
> > OK, that pile ought to take care of a lot of nastiness. ?We still have
> > rather messy crap in attributes' handling, but it's actually getting
> > cleaner now. ?In particular, direct_declarator and declaration_specifiers
> > are relatively sane, handling of type specifiers should be correct now (and
> > much cleaner than it used to be) and most of the tangled mess around
> > attributes is untangled. ?Still a mess, but at least doing something
> > about it becomes feasible...
> >
> 
> I really like these series of patches. All applied.
> 
> It is much cleaner now.
> 
> BTW, what does Set_S and Set_T means? Symbol and type?

s/symbol/solitary/, actually (it's used for the things that don't mix with
other specifiers at all).  T is more or less "type" - it's for the large
group of specifiers that are mutually exclusive (int/char/double/float/all
solitary ones - the only things that are *not* part of that set are
signed/unsigned/long/short).  For the sake of completeness, Set_Vlong (used
to track having seen "long" twice) comes from the name Plan 9 C compiler
used (pre-C99) for long long; they call it vlong, presumably with "v" for
"very".

FWIW, float could be considered solitary too, if not for (yet to be supported)
_Complex.  Parser-side modifications to support that would be fairly simple,
especially if we support gcc extensions[1].  Of course, we'd need to deal
with that more than just in parser - expand.c and evaluate.c at the very
least, and we'd need new EXPR_... node types for constant values...


[1] C99 gives parser a bit of a wart since _Complex, _Complex long and
long _Complex are not accepted, so we get valid combinations that have
invalid prefices; not a big deal.  Requires slightly different definition
for complex_op and an extra check and warning in the end of process.
gcc, out of either laziness or sheer insanity allows complex for *any*
arithmetic types, even though e.g. complex char makes no sense whatsoever,
so it's even simpler for parser to deal with.

      reply	other threads:[~2009-03-10 22:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-09  7:10 [patches] more declarations fixes Al Viro
2009-03-09 22:55 ` Christopher Li
2009-03-09 23:32   ` Al Viro
2009-03-09 23:53     ` Christopher Li
2009-03-10 21:27 ` Christopher Li
2009-03-10 22:42   ` Al Viro [this message]

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=20090310224214.GU28946@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=linux-sparse@vger.kernel.org \
    --cc=sparse@chrisli.org \
    --cc=viro@ftp.linux.org.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.