public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
From: neil@gcc.gnu.org
To: dick_schoeller@bmc.com, eric_dana@bmc.com, gcc-bugs@gcc.gnu.org,
	gcc-prs@gcc.gnu.org, neil@gcc.gnu.org
Subject: Re: preprocessor/5806: The preprocessor evaluates expression s in 64-bit, violating IS C++ 16.1.4
Date: Mon, 27 May 2002 13:35:00 -0000	[thread overview]
Message-ID: <20020527192221.15236.qmail@sources.redhat.com> (raw)

Synopsis: The preprocessor evaluates expression s in 64-bit, violating IS C++ 16.1.4

State-Changed-From-To: analyzed->closed
State-Changed-By: neil
State-Changed-When: Mon May 27 12:22:20 2002
State-Changed-Why:
    After some recent patches of mine, GCC 3.2 does preprocessor arithmetic to the precision of the target's intmax_t, as required by the C99 standard.
    
    As you can see from a discussion in the last two days on GCC-patches mailing list, it was decided that we should do this in C89 mode as well, otherwise there is no consistent way for us to have the long-long extension.
    
    Now, you claim it violates the ISO C++ and C89 standards.  In fact it does not; if you read the relevant section carefully, it says that CPP arithmetic is done to *at least* the precision of the target "long" type.  By using intmax_t, we are in compliance with this requirement:
    
    "... the controlling constant expression ... is evaluated according to the rules of 6.4 using arithmetic that has *at least* the ranges specified in 5.2.4.2, except that int and unsigned int act as if they have the same representation as, respectively, long and unsigned long."
    
    Because of this wording, any code that relied on the C89 preprocessor to determine properties of the target machine precision was always broken.
    
    Thanks for the bug report.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5806


             reply	other threads:[~2002-05-27 19:22 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-27 13:35 neil [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-08-05 15:26 Dana, Eric
2002-08-03  0:56 'Zack Weinberg'
2002-05-26 12:16 neil
2002-03-25  0:53 neil
2002-03-15  8:56 Dana, Eric
2002-03-14 15:16 'Zack Weinberg'
2002-03-14 13:06 'Neil Booth'
2002-03-14 13:06 Dana, Eric
2002-03-14 11:46 Zack Weinberg
2002-03-01 15:16 Neil Booth
2002-03-01 13:36 Zack Weinberg
2002-03-01 12:16 eric_dana

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=20020527192221.15236.qmail@sources.redhat.com \
    --to=neil@gcc.gnu.org \
    --cc=dick_schoeller@bmc.com \
    --cc=eric_dana@bmc.com \
    --cc=gcc-bugs@gcc.gnu.org \
    --cc=gcc-gnats@gcc.gnu.org \
    --cc=gcc-prs@gcc.gnu.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 read-only IMAP folder(s) and NNTP newsgroup(s).