From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12949 invoked by alias); 7 Nov 2002 09:26:02 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 12935 invoked by uid 71); 7 Nov 2002 09:26:01 -0000 Date: Thu, 07 Nov 2002 01:26:00 -0000 Message-ID: <20021107092601.12933.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: "Christian Ehrhardt" Subject: Re: preprocessor/8449: Ellipsis in 3...5 not recognized properly Reply-To: "Christian Ehrhardt" X-SW-Source: 2002-11/txt/msg00360.txt.bz2 List-Id: The following reply was made to PR preprocessor/8449; it has been noted by GNATS. From: "Christian Ehrhardt" To: Neil Booth 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!