preprocessor/8449: Ellipsis in 3...5 not recognized properly

preprocessor/8449: Ellipsis in 3...5 not recognized properly

[ehrhardt]

>Number:         8449
>Category:       preprocessor
>Synopsis:       Ellipsis in 3...5 not recognized properly
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          rejects-legal
>Submitter-Id:   net
>Arrival-Date:   Mon Nov 04 08:26:00 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     Christian Ehrhardt
>Release:        gcc-3.2
>Organization:
>Environment:
Reading specs from /usr/local/bin/../lib/gcc-lib/sparc-sun-solaris2.9/3.2/specs
Configured with: /export/local/manager/playground/ULMgcc32/src/gcc-3.2/configure --with-ld=/usr/local/bin/ld --with-gnu-ld --with-as=/usr/local/bin/as --with-gnu-as --prefix=/usr/local/
Thread model: posix
gcc version 3.2
SunOS perseus 5.9 Generic_112233-01 sun4u sparc SUNW,Ultra-5_10
>Description:
Compiling this:

int a[2] = {[0 ...1]=1};

with gcc -c t.c gives an error:
gcc -c t9.c
t9.c:1: too many decimal points in floating constant
The cause is quite obious: The ellipsis is parsed as part of the
number. Something along these lines might fix it (only compile tested
as of yet)

--- cpplex.c.old	Mon Nov  4 17:15:08 2002
+++ cpplex.c	Mon Nov  4 17:14:45 2002
@@ -527,6 +527,7 @@
 {
   cpp_buffer *buffer = pfile->buffer;
   unsigned char *dest, *limit;
+  int dotdot = 0;
 
   dest = BUFF_FRONT (pfile->u_buff);
   limit = BUFF_LIMIT (pfile->u_buff);
@@ -547,6 +548,11 @@
     {
       do
 	{
+	  /* Is this potentially an ellipsis? */
+	  if (c == '.' && *(buffer->cur+1) == '.') {
+	    dotdot = 1;
+	    break;
+	  }
 	  /* Need room for terminating null.  */
 	  if ((size_t) (limit - dest) < 2)
 	    {
@@ -563,6 +569,8 @@
 
       /* Potential escaped newline?  */
       buffer->backup_to = buffer->cur - 1;
+      if (dotdot)
+        break;
       if (c != '?' && c != '\\')
 	break;
       c = skip_escaped_newlines (pfile);
>How-To-Repeat:
See above.
>Fix:
Add a space before the ellipsis.
>Release-Note:
>Audit-Trail:
>Unformatted:

Re: preprocessor/8449: Ellipsis in 3...5 not recognized properly

[neil]

Synopsis: Ellipsis in 3...5 not recognized properly

State-Changed-From-To: open->closed
State-Changed-By: neil
State-Changed-When: Thu Nov  7 03:38:23 2002
State-Changed-Why:
    Not a bug.   0...1 is a single token, a preprocessing number.  When the compiler tries to interpret the number, it complains about the excess '.' like you saw, which is correct.
    
    You need to add a space to break it into two tokens, like you actually did in your report.

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

Re: preprocessor/8449: Ellipsis in 3...5 not recognized properly

[Andreas Schwab]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1005 bytes --]

The following reply was made to PR preprocessor/8449; it has been noted by GNATS.

From: Andreas Schwab <schwab@suse.de>
To: "Christian Ehrhardt" <ehrhardt@mathematik.uni-ulm.de>
Cc: Neil Booth <neil@daikokuya.co.uk>, gcc-gnats@gcc.gnu.org,
	gcc-bugs@gcc.gnu.org
Subject: Re: preprocessor/8449: Ellipsis in 3...5 not recognized properly
Date: Thu, 07 Nov 2002 12:09:54 +0100

 "Christian Ehrhardt" <ehrhardt@mathematik.uni-ulm.de> writes:
 
 |> int a[2] = {[0...1] = 1};
 
 This is a constraint violation.  0...1 is a preprocessing token (a
 pp-number, 6.4.8), but not a token, thus it violates 6.4[#2]: "Each
 preprocessing token that is converted to a token shall have the lexical
 form of a keyword, an identifier, a constant, a string literal, or a
 punctuator."
 
 Andreas.
 
 -- 
 Andreas Schwab, SuSE Labs, schwab@suse.de
 SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
 Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
 "And now for something completely different."

Re: preprocessor/8449: Ellipsis in 3...5 not recognized properly

[Christian Ehrhardt]

The following reply was made to PR preprocessor/8449; it has been noted by GNATS.

From: "Christian Ehrhardt" <ehrhardt@mathematik.uni-ulm.de>
To: Neil Booth <neil@daikokuya.co.uk>
Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org
Subject: Re: preprocessor/8449: Ellipsis in 3...5 not recognized properly
Date: Thu, 7 Nov 2002 10:23:10 +0100

 On Thu, Nov 07, 2002 at 08:24:59AM +0000, Neil Booth wrote:
 > ehrhardt@mathematik.uni-ulm.de wrote:-
 > 
 > > Compiling this:
 > > 
 > > int a[2] = {[0 ...1]=1};
 
 Aaaarg! Sorry! This my fault. The synopsis has the proper problem case
 if there actually is no space after the range start. Also see the ``Fix''
 section where putting the space before the ellipsis is mentioned as a
 work around.
 
 Here's a typescript from a shell session:
 
 Script started on Thu Nov 07 10:02:22 2002
 theseus$ cat wrong.c
 int a[2] = {[0...1] = 1};
 theseus$ gcc -c wrong.c
 wrong.c:1: too many decimal points in floating constant
 theseus$ exit
 
 script done on Thu Nov 07 10:02:35 2002
 
 
 > > with gcc -c t.c gives an error:
 > > gcc -c t9.c
 > > t9.c:1: too many decimal points in floating constant
 > > The cause is quite obious: The ellipsis is parsed as part of the
 > > number. Something along these lines might fix it (only compile tested
 > > as of yet)
 > 
 > As I expected, I couldn't reproduce this.  Could you elaborate?
 > Are you using stock GCC?  The code in cpplex.c IMO clearly handles
 > ellipses correctly, even with escaped newlines, and has nothing to
 > do with numbers:
 > 
 >     case '.':
 >       result->type = CPP_DOT;
 >       c = get_effective_char (pfile);
 >       if (c == '.')
 > 	{
 > 	  const unsigned char *pos = buffer->cur;
 > 
 > 	  if (get_effective_char (pfile) == '.')
 > 	    result->type = CPP_ELLIPSIS;
 > 	  else
 > 	    buffer->cur = pos - 1;
 > 	}
 > 
 > So, assuming the case '.' code is reached, which it would appear to
 > be since the "..." appears after whitespace (which causes a loop back
 > to re-enter the switch) I don't see how this can fail.
 
 Ok, assume there is no space between the digit '0' and the first '.' of
 the ellipsis (as should have been stated in the original report, sorry
 again). In this cases when we reach the '0' we call parse_number. This
 function will consume an aribrary sequence of dots, digits and possibly
 other characters in the number, i.e. the token parsed is the "number"
 "0...1" instead of number "0" followed by an ellipsis followed by number "1".
 
 This is basically the loop that does this, it is first entered with
 c == '0'.
 
       do
         {
           /* Need room for terminating null.  */
           if ((size_t) (limit - dest) < 2)
             {
               size_t len_so_far = dest - BUFF_FRONT (pfile->u_buff);
               _cpp_extend_buff (pfile, &pfile->u_buff, 2);
               dest = BUFF_FRONT (pfile->u_buff) + len_so_far;
               limit = BUFF_LIMIT (pfile->u_buff);
             }
           *dest++ = c;
 
           c = *buffer->cur++;
         }
       while (is_numchar (c) || c == '.' || VALID_SIGN (c, dest[-1]));
 
 > What ASCII character is after the '0' in your line above?  Maybe it's
 > not be the space it appears to be.
 
 Exactly :-( The character is a dot ('.'). Thanks for looking into this.
 Should I file a new corrected PR or does this sufficiently clarify
 the problem?
 
      regards   Christian Ehrhardt
 
 -- 
 THAT'S ALL FOLKS!

Re: preprocessor/8449: Ellipsis in 3...5 not recognized properly

[Neil Booth]

The following reply was made to PR preprocessor/8449; it has been noted by GNATS.

From: Neil Booth <neil@daikokuya.co.uk>
To: ehrhardt@mathematik.uni-ulm.de
Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org
Subject: Re: preprocessor/8449: Ellipsis in 3...5 not recognized properly
Date: Thu, 7 Nov 2002 08:24:59 +0000

 ehrhardt@mathematik.uni-ulm.de wrote:-
 
 > Compiling this:
 > 
 > int a[2] = {[0 ...1]=1};
 > 
 > with gcc -c t.c gives an error:
 > gcc -c t9.c
 > t9.c:1: too many decimal points in floating constant
 > The cause is quite obious: The ellipsis is parsed as part of the
 > number. Something along these lines might fix it (only compile tested
 > as of yet)
 
 As I expected, I couldn't reproduce this.  Could you elaborate?
 Are you using stock GCC?  The code in cpplex.c IMO clearly handles
 ellipses correctly, even with escaped newlines, and has nothing to
 do with numbers:
 
     case '.':
       result->type = CPP_DOT;
       c = get_effective_char (pfile);
       if (c == '.')
 	{
 	  const unsigned char *pos = buffer->cur;
 
 	  if (get_effective_char (pfile) == '.')
 	    result->type = CPP_ELLIPSIS;
 	  else
 	    buffer->cur = pos - 1;
 	}
 
 So, assuming the case '.' code is reached, which it would appear to
 be since the "..." appears after whitespace (which causes a loop back
 to re-enter the switch) I don't see how this can fail.
 
 What ASCII character is after the '0' in your line above?  Maybe it's
 not be the space it appears to be.
 
 Neil.

Re: preprocessor/8449: Ellipsis in 3...5 not recognized properly

[Christian Ehrhardt]

The following reply was made to PR preprocessor/8449; it has been noted by GNATS.

From: "Christian Ehrhardt" <ehrhardt@mathematik.uni-ulm.de>
To: gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org,
  ehrhardt@mathematik.uni-ulm.de, gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org
Cc:  
Subject: Re: preprocessor/8449: Ellipsis in 3...5 not recognized properly
Date: Mon, 4 Nov 2002 17:51:14 +0100

 Hi,
 
 sorry for the self followup but: gcc version 3.3 20021101 (experimental)
 gives an ICE after the error (segmentationfault):
 $ gcc -Wall t.c
 t9.c:1:14: too many decimal points in number
 t9.c:1: internal compiler error: Segmentation Fault
 Please submit a full bug report,
 with preprocessed source if appropriate.
 See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
 
 An even worse test case not fixed by the previous patch is with an escaped
 newline in the middle of the ellipsis:
 
 int a[2] = {[0 .\
 ..1] = 2};
 
     regards   Christian Ehrhardt
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8449
 
 -- 
 THAT'S ALL FOLKS!