[Bug preprocessor/12607] New: preprocessor fails to diagnose an undefined ## result

[Bug preprocessor/12607] New: preprocessor fails to diagnose an undefined ## result

[sebor at roguewave dot com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12607

           Summary: preprocessor fails to diagnose an undefined ## result
           Product: gcc
           Version: 3.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: preprocessor
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: sebor at roguewave dot com
                CC: gcc-bugs at gcc dot gnu dot org

The preprocessor issues an error for the case marked #1 in the program below but
fails to diagnose a similar construct marked #2. In neither instance the result
of the ## operator yields a single valid pp-token. For consistency I suggest
that gcc diagnose both cases.

Additionally, to make porting to gcc from more permissive compilers (no other
compiler gives an error for this by default) easier, I suggest that these cases
be only flagged as warnings when -Wall is used (and silently accepted otherwise)
and turned into hard errors only when -Werror is used.

Thanks
Martin

$ catnc t.cpp && gcc -E t.cpp
/*   1 */ #define CAT(a, b)   a ## b
/*   2 */ 
/*   3 */ struct S { enum { ab }; } s;
/*   4 */ 
/*   5 */ int i = CAT (1+, 2);    // #1
/*   6 */ int j = CAT (s.a, b);   // #2
# 1 "t.cpp"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "t.cpp"


struct S { enum { ab }; } s;

t.cpp:5:19: pasting "+" and "2" does not give a valid preprocessing token
int i = 1 + 2;
int j = s.ab;

[Bug preprocessor/12607] preprocessor fails to diagnose an undefined ## result

[pinskia at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12607


pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


------- Additional Comments From pinskia at gcc dot gnu dot org  2003-10-14 00:08 -------
The error should not be there for #2, because it does paste "a" and "b" together into ab, see the 
preprocessed code.

[Bug preprocessor/12607] preprocessor fails to diagnose an undefined ## result

[sebor at roguewave dot com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12607



------- Additional Comments From sebor at roguewave dot com  2003-10-14 00:29 -------
I think you may have misunderstood the complaint: 16.3.3, p3 says that "If the
result [of operator ##] is not a valid preprocessing token, the behavior is
undefined." gcc chooses to give an error in the case #1 where the result of
concatenating 1+ and 1 is not a valid pp-token, but it fails to do so in the
case #2, where the result of concatenting s.a and b is also not a valid
pp-token. In both cases, the result is a sequence of three valid tokens, but
that's apparently not relevant. My complaint is about the inconsistency in how
gcc treats these two cases of undefined behavior.

Thanks
Martin

[Bug preprocessor/12607] preprocessor fails to diagnose an undefined ## result

[pinskia at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12607



------- Additional Comments From pinskia at gcc dot gnu dot org  2003-10-14 00:41 -------
But since s.a is already three different tokens, "s", ".", and "a".  it is split up and the last one is 
concatenated with the "b".

[Bug preprocessor/12607] preprocessor fails to diagnose an undefined ## result

[sebor at roguewave dot com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12607



------- Additional Comments From sebor at roguewave dot com  2003-10-14 01:00 -------
I see. I think I agree with you: it's the pp-token immediatley preceding the ##
operator that, after concatenation, must form another valid token, and it is not
required that the pp-token (or sequence thereof) substituted for the macro
parameter form a single valid token after concatentation. Looks like HP
misinterpreted this the same way I did -- their preprocessor complains (see below).

I would still appreciate if the request to turn this into a warning and only
with -Wall were considered :)

Thanks
Martin

Warning (anachronism) 823: "t.cpp", line 6 # Redundant preprocessing
concatenation operation results in two valid preprocessing tokens. Depending on
this implementation defined behavior will result in non-portable code.
    /*   6 */ int j = CAT (s.a, b);   // #2
                           ^               
 int j = s.ab ;

Re: [Bug preprocessor/12607] preprocessor fails to diagnose an undefined ## result

[Neil Booth]

sebor at roguewave dot com wrote:-

> I see. I think I agree with you: it's the pp-token immediatley preceding the ##
> operator that, after concatenation, must form another valid token, and it is not
> required that the pp-token (or sequence thereof) substituted for the macro
> parameter form a single valid token after concatentation. Looks like HP
> misinterpreted this the same way I did -- their preprocessor complains (see below).

But "sequence thereof" is a useless concept in this context.  The stand
is quite clear - ## pastes just two tokens to create a token.

> Warning (anachronism) 823: "t.cpp", line 6 # Redundant preprocessing
> concatenation operation results in two valid preprocessing tokens. Depending on
> this implementation defined behavior will result in non-portable code.
>     /*   6 */ int j = CAT (s.a, b);   // #2
>                            ^               
>  int j = s.ab ;

This is simply wrong.  I bet you can't find a single compiler that
gets this wrong.  Further, there is nothing redundant about the ##;
if any compiler works in the way you intend with it *missing* then that
compiler is buggy.  I suggest you report this as a bug to EDG.

Neil.

[Bug preprocessor/12607] preprocessor fails to diagnose an undefined ## result

[neil at daikokuya dot co dot uk]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12607



------- Additional Comments From neil at daikokuya dot co dot uk  2003-10-14 05:50 -------
Subject: Re:  preprocessor fails to diagnose an undefined ## result

sebor at roguewave dot com wrote:-

> I see. I think I agree with you: it's the pp-token immediatley preceding the ##
> operator that, after concatenation, must form another valid token, and it is not
> required that the pp-token (or sequence thereof) substituted for the macro
> parameter form a single valid token after concatentation. Looks like HP
> misinterpreted this the same way I did -- their preprocessor complains (see below).

But "sequence thereof" is a useless concept in this context.  The stand
is quite clear - ## pastes just two tokens to create a token.

> Warning (anachronism) 823: "t.cpp", line 6 # Redundant preprocessing
> concatenation operation results in two valid preprocessing tokens. Depending on
> this implementation defined behavior will result in non-portable code.
>     /*   6 */ int j = CAT (s.a, b);   // #2
>                            ^               
>  int j = s.ab ;

This is simply wrong.  I bet you can't find a single compiler that
gets this wrong.  Further, there is nothing redundant about the ##;
if any compiler works in the way you intend with it *missing* then that
compiler is buggy.  I suggest you report this as a bug to EDG.

Neil.

[Bug preprocessor/12607] preprocessor fails to diagnose an undefined ## result

[sebor at roguewave dot com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12607



------- Additional Comments From sebor at roguewave dot com  2003-10-14 15:30 -------
I did (send it to HP :) They agree it's a bug in aCC.

Any comments on the -Wall/-Werror request?

Martin

Re: [Bug preprocessor/12607] preprocessor fails to diagnose an undefined ## result

[Neil Booth]

sebor at roguewave dot com wrote:-

> PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12607
> 
> 
> 
> ------- Additional Comments From sebor at roguewave dot com  2003-10-14 15:30 -------
> I did (send it to HP :) They agree it's a bug in aCC.
> 
> Any comments on the -Wall/-Werror request?

Uhh, we seem to have agreed there is nothing to warn about.  In any
case, I don't want a warning added; I certainly believe there is nothing
to warn about.

Neil.

[Bug preprocessor/12607] preprocessor fails to diagnose an undefined ## result

[neil at daikokuya dot co dot uk]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12607



------- Additional Comments From neil at daikokuya dot co dot uk  2003-10-14 20:30 -------
Subject: Re:  preprocessor fails to diagnose an undefined ## result

sebor at roguewave dot com wrote:-

> PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12607
> 
> 
> 
> ------- Additional Comments From sebor at roguewave dot com  2003-10-14 15:30 -------
> I did (send it to HP :) They agree it's a bug in aCC.
> 
> Any comments on the -Wall/-Werror request?

Uhh, we seem to have agreed there is nothing to warn about.  In any
case, I don't want a warning added; I certainly believe there is nothing
to warn about.

Neil.

[Bug preprocessor/12607] preprocessor fails to diagnose an undefined ## result

[sebor at roguewave dot com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12607



------- Additional Comments From sebor at roguewave dot com  2003-10-14 20:57 -------
Sorry, I should have perhaps been more specific. Let me reiterate my suggestion:
replace the hard error in case #1 (undefined behavior) with a warning when -Wall
is on the command line, silently accept it when it isn't, and have -Werror turn
the warning into a hard error.

The value in this feature (i.e., permissive behavior) is in making it easier to
port to gcc programs that rely on this sort of undefined behavior from compilers
that accept the construct.

Martin

[Bug preprocessor/12607] preprocessor fails to diagnose an undefined ## result

[sebor at roguewave dot com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12607



------- Additional Comments From sebor at roguewave dot com  2003-10-16 16:18 -------
While talking to HP about their bugs in operator ## it came up that the program
below relies on undefined behavior since the order of evaluation of the operator
is unspecified. I think it might be useful to issue a portability warning in
this case when -Wall is on the command line.

$ cat t.cpp && gcc -Wall -E t.cpp
#define CAT3(a, b, c)   a ## b ## c

CAT3 (-, >, *)
# 1 "t.cpp"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "t.cpp"


->*

[Bug preprocessor/12607] preprocessor fails to diagnose an undefined ## result

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-09-28 04:04 -------
Reopening to ...

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12607

[Bug preprocessor/12607] preprocessor fails to diagnose an undefined ## result

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-09-28 04:05 -------
Mark this as a dup of bug 7976.

*** This bug has been marked as a duplicate of 7976 ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12607