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!