Re: c/4513: Preprocessor appears broken for the '#' operator

Re: c/4513: Preprocessor appears broken for the '#' operator

[neil]

Synopsis: Preprocessor appears broken for the '#' operator

State-Changed-From-To: open->closed
State-Changed-By: neil
State-Changed-When: Wed Oct 10 01:18:25 2001
State-Changed-Why:
    Strictly not a bug, but handled properly in 3.0 anyway.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=4513&database=gcc

Re: c/4513: Preprocessor appears broken for the '#' operator

[Zack Weinberg]

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

From: Zack Weinberg <zack@codesourcery.com>
To: Neil Booth <neil@daikokuya.demon.co.uk>
Cc: dgillies@graviton.com, gcc-gnats@gcc.gnu.org
Subject: Re: c/4513: Preprocessor appears broken for the '#' operator
Date: Wed, 10 Oct 2001 14:42:08 -0700

 On Wed, Oct 10, 2001 at 07:47:35AM +0100, Neil Booth wrote:
 > > I'm also inclined to say that it is reasonable to dislike what 3.0
 > > does, and I'll listen to discussion about whether or not #\ should
 > > become "\\".  However, I remember that there was a good reason why we
 > > didn't do that in the first place.  Neil, do you remember what it was?
 > 
 > No good reason, I think it was the simplest implementation (simply
 > decrement the length).  I imagine it's very easy to append a '\' too;
 > if you do this be sure that there's enough room for the '\'.
 > (Checks): there is, since cpp_token_len returns conservative lengths.
 > I don't mind which we do.
 
 I don't see much point in changing it unless someone comes up with an
 example of real life code which wants the other behavior.
 
 zw

Re: c/4513: Preprocessor appears broken for the '#' operator

[Neil Booth]

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

From: Neil Booth <neil@daikokuya.demon.co.uk>
To: Zack Weinberg <zack@codesourcery.com>
Cc: dgillies@graviton.com, gcc-gnats@gcc.gnu.org
Subject: Re: c/4513: Preprocessor appears broken for the '#' operator
Date: Wed, 10 Oct 2001 07:47:35 +0100

 Zack Weinberg wrote:-
 
 > Note the error messages in each case.  The reason 2.95 does not expand
 > STR2 or MAKESTRING2 is that it processes #\ into "\", and interprets
 > that as the beginning of a multi-line string constant, running on into
 > the rest of the file.  Since it's inside a string constant, of course
 > macros are not expanded.
 
 8-)  What a mess.
 
 > I'm also inclined to say that it is reasonable to dislike what 3.0
 > does, and I'll listen to discussion about whether or not #\ should
 > become "\\".  However, I remember that there was a good reason why we
 > didn't do that in the first place.  Neil, do you remember what it was?
 
 No good reason, I think it was the simplest implementation (simply
 decrement the length).  I imagine it's very easy to append a '\' too;
 if you do this be sure that there's enough room for the '\'.
 (Checks): there is, since cpp_token_len returns conservative lengths.
 I don't mind which we do.
 
 Whatever we do, we should retain a warning appropriate to how we
 adjust the string literal.
 
 Neil.

Re: c/4513: Preprocessor appears broken for the '#' operator

[Zack Weinberg]

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

From: Zack Weinberg <zack@codesourcery.com>
To: dgillies@graviton.com
Cc: Neil Booth <neil@daikokuya.demon.co.uk>, gcc-gnats@gcc.gnu.org
Subject: Re: c/4513: Preprocessor appears broken for the '#' operator
Date: Tue, 9 Oct 2001 22:22:33 -0700

 On Wed, Oct 10, 2001 at 01:51:07AM -0000, dgillies@graviton.com wrote:
 
 > #define STR2(X)          #X
 > #define MAKESTRING1(X)   STR2(\) STR2(X)
 > #define MAKESTRING2(X)   STR2(X) STR2(\) 
 ...
 
 Expanding this to a complete test case:
 
 #define STR2(X)          #X
 #define MAKESTRING1(X)   STR2(\) STR2(X)
 #define MAKESTRING2(X)   STR2(X) STR2(\)
 #define CONST 0300
 MAKESTRING1(CONST)
 MAKESTRING2(CONST)
 
 2.95.4 branch, 20010902 snapshot:
 
 tst.c:5: unterminated string or character constant
 tst.c:5: possible real start of unterminated constant
 # 1 "tst.c"
 
 
 
 
 "\"
   STR2(
  0300
  
  )
  
 MAKESTRING2(CONST)
 
 3.0.2 branch, 20010922 snapshot:
 
 tst.c:5:1: warning: invalid string literal, ignoring final '\'
 # 5 "tst.c"
 "" "0300"
 tst.c:6:1: warning: invalid string literal, ignoring final '\'
 "0300" ""
 
 Mainline matches 3.0.x.
 
 Note the error messages in each case.  The reason 2.95 does not expand
 STR2 or MAKESTRING2 is that it processes #\ into "\", and interprets
 that as the beginning of a multi-line string constant, running on into
 the rest of the file.  Since it's inside a string constant, of course
 macros are not expanded.
 
 3.0.x will not do this kind of violence to token boundaries.  Instead,
 it deletes the backslash in order to make a valid string literal out
 of "\".
 
 The C standard explicitly says that the result of stringification of a
 single backslash is "\", _not_ "\\" as you might have expected.  It
 does then go on to say that, as "\" is not a valid string literal, the
 behavior is undefined - so we are allowed to translate "\" into "\\"
 if we want, or to do what 3.0 does, _or_ to do what 2.95 does.
 
 I'm inclined to say that 3.0.2's behavior is preferable to 2.95.x's,
 but that it's not worth trying to get 2.95 to do what 3.0 does (the
 preprocessor was completely rewritten between 2.x and 3.x).  
 
 I'm also inclined to say that it is reasonable to dislike what 3.0
 does, and I'll listen to discussion about whether or not #\ should
 become "\\".  However, I remember that there was a good reason why we
 didn't do that in the first place.  Neil, do you remember what it was?
 
 zw

Re: c/4513: Preprocessor appears broken for the '#' operator

[Carlo Wood]

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

From: Carlo Wood <carlo@alinoe.com>
To: dgillies@graviton.com
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: c/4513: Preprocessor appears broken for the '#' operator
Date: Wed, 10 Oct 2001 06:00:50 +0200

 On Wed, Oct 10, 2001 at 01:51:07AM -0000, dgillies@graviton.com wrote:
 > >Description:
 > #define STR2(X)          #X
 > #define MAKESTRING1(X)   STR2(\) STR2(X)
 > #define MAKESTRING2(X)   STR2(X) STR2(\) 
 > 
 > Just look at the #defines above.  Don't you expect commutative
 > results when i evaluate MAKESTRING1() and MAKESTRING2() ??
 > 
 > #define CONST 0300
 > 
 > then
 > 
 > MAKESTRING1(CONST) = "\" STR2(CONST)
 > MAKESTRING2(CONST) = "0300" "\"
 > 
 > I think the preprocessor gets confused when i stringify
 > the '\' for MAKESTRING1().  The second part of MAKESTRING1()
 > should be "0300", i believe.
 
 I looked at the standard, and I am not sure what should happen :/.
 Imho, the code is ill-formed.
 
 However, on all compiler versions I have installed, this "worked"
 (results in what you expected:
 
 "\" "0300"
 "0300" "\"
 
 ).
 I tried 2.95.1, 2.95.2, 2.95.3, 2.96-69 (redhat), 3.0, 3.0.1, 3.0.2 prerelease
 and a recent 3.1.  (I am using i686-gnu-linux).
 
 -- 
 Carlo Wood <carlo@alinoe.com>

c/4513: Preprocessor appears broken for the '#' operator

[dgillies]

>Number:         4513
>Category:       c
>Synopsis:       Preprocessor appears broken for the '#' operator
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Oct 09 18:56:00 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     dgillies@graviton.com <Donald W. Gillies>
>Release:        unknown-1.0
>Organization:
>Environment:
FreeBSD 4.2
Using builtin specs.
gcc version 2.95.2 19991024 (release)
>Description:
#define STR2(X)          #X
#define MAKESTRING1(X)   STR2(\) STR2(X)
#define MAKESTRING2(X)   STR2(X) STR2(\) 

Just look at the #defines above.  Don't you expect commutative
results when i evaluate MAKESTRING1() and MAKESTRING2() ??

#define CONST 0300

then

MAKESTRING1(CONST) = "\" STR2(CONST)
MAKESTRING2(CONST) = "0300" "\"

I think the preprocessor gets confused when i stringify
the '\' for MAKESTRING1().  The second part of MAKESTRING1()
should be "0300", i believe.

- Don Gillies
Graviton, 858-909-2130
gillies@cs.ubc.ca
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: