From: Al Viro <viro@ftp.linux.org.uk>
To: Neil Booth <neil@daikokuya.co.uk>
Cc: Josh Triplett <josh@freedesktop.org>,
linux-sparse@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: fun with ?:
Date: Wed, 23 May 2007 16:32:55 +0100 [thread overview]
Message-ID: <20070523153255.GA4095@ftp.linux.org.uk> (raw)
In-Reply-To: <20070523144716.GC2547@daikokuya.co.uk>
On Wed, May 23, 2007 at 11:47:16PM +0900, Neil Booth wrote:
> > gcc integer constant expressions handling is a bad joke.
> >
> > extern int n;
> > struct {
> > int x : 1 + n - n;
> > } y;
> >
> > passes with -pedantic -std=c99. Replacing that with 1 + n - n + n - n
> > is still OK with gcc; 1 + n + n - n - n is not.
> >
> > So that's hardly an example of, well, anything.
>
> Consistency? :-) I wasn't aware of the quirk of the second example.
>
> Apparently these expressions are only folded if their net result
> is obvious as parsed by the grammar. Fixing this in GCC is a
> horrendous amount of work; so much internal logic relies on this
> early simplification, which is why it's not been done I guess.
With sparse that's easier - we have parsing and typechecking separated
enough. And yes, blind evaluate + expand will suffer similar problems.
However, it's not hard to have evaluate_expression() to set a flag
when it steps into a construct prohibited in integer constant expressions.
BTW, immediate cast from float is not hard - you need all casts other than
under sizeof go to integer type *and* you need any operations involving
floating point types to set "not an integer constant expression". Since
comma and function calls are also banned, float will either go all
way up or it will be eaten by cast.
BTW, the fun question is whether (int)(1.1) is allowed; the same goes
for "is ((void *)0) a null pointer constant". 6.5.1 is sloppy ;-)
next prev parent reply other threads:[~2007-05-23 15:32 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-19 2:52 fun with ?: Al Viro
2007-05-22 21:40 ` Josh Triplett
2007-05-22 22:46 ` Al Viro
2007-05-22 23:24 ` Josh Triplett
2007-05-23 0:02 ` Al Viro
2007-05-23 0:25 ` Al Viro
2007-05-23 1:05 ` Josh Triplett
2007-05-23 4:53 ` Al Viro
2007-05-23 12:26 ` Morten Welinder
2007-05-23 1:03 ` Josh Triplett
2007-06-03 1:05 ` Al Viro
2007-05-23 14:25 ` Neil Booth
2007-05-23 14:32 ` Al Viro
2007-05-23 14:47 ` Neil Booth
2007-05-23 15:32 ` Al Viro [this message]
2007-05-23 23:01 ` Neil Booth
2007-05-24 0:10 ` Derek M Jones
2007-05-24 0:14 ` Al Viro
2007-05-23 21:16 ` Derek M Jones
2007-05-23 21:59 ` Linus Torvalds
2007-05-23 23:29 ` Derek M Jones
2007-05-24 0:02 ` Al Viro
2007-05-24 0:29 ` Linus Torvalds
2007-05-24 1:36 ` Brett Nash
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=20070523153255.GA4095@ftp.linux.org.uk \
--to=viro@ftp.linux.org.uk \
--cc=josh@freedesktop.org \
--cc=linux-sparse@vger.kernel.org \
--cc=neil@daikokuya.co.uk \
--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).