Bug 7976 - pasting xxx and xxx does not give a valid preprocessing token
Summary: pasting xxx and xxx does not give a valid preprocessing token
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: preprocessor (show other bugs)
Version: 3.1
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 9689 12513 12607 16275 17299 17304 17638 24098 25170 (view as bug list)
Depends on:
Blocks:
 
Reported: 2002-09-19 04:46 UTC by stoppel
Modified: 2012-11-20 01:13 UTC (History)
10 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:

Attachments
cpp-define.c (341 bytes, application/octet-stream)
2003-05-21 15:17 UTC, stoppel 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description stoppel 2002-09-19 04:46:02 UTC 
Execution of some mocro definition yield unexpected results:
"cpp" reports:
> 
> cpp-define.c:22:13 warning: pasting ")" and "l"
> does not give a valid preprocessing token
>

Release:
gcc version 3.1

Environment:
HPUX 10.20 hw:K460, HPUX 11.00 hw:J5000, GNU/Linux Debian 2.2.17

How-To-Repeat:
"cpp-define.c" is the attached file
gcc -E cpp cpp-define.c
cpp cpp-define.c
Comment 1 stoppel 2002-09-19 04:46:02 UTC 
Fix:
I do not know.
Comment 2 Neil Booth 2002-09-19 06:11:22 UTC 
State-Changed-From-To: open->closed
State-Changed-Why: Not a bug.  You have a ## in your macro definition that
    is being used to create a token from ")" and "l" by
    concatenation.  No such token exists.
    
    You can probably remove the ## in question.
Comment 3 Neil Booth 2002-09-19 06:13:38 UTC 
State-Changed-From-To: closed->open
State-Changed-Why: Sorry, ignore previous message.  I'll look at this later.
Comment 4 Neil Booth 2002-09-19 06:19:59 UTC 
State-Changed-From-To: open->closed
State-Changed-Why: Not a bug.
    
    #define __CONCAT__(_A,_B) _A ## _B
    #define __CONCAT_U__(_A) _A ## u
    #define UINT32_C(__c) __CONCAT__(__CONCAT_U__(__c),l)
    UINT32_C(123)
    
    The bug in your macro occurs during the expansion of UINT32_C.  Since, in the definition of __CONCAT__, the
    first argument is operated on by ##, it is not expanded
    before replacement.  Therefore, the first stage of
    expansion is
    UINT32_C(123)
    __CONCAT__(__CONCAT_U__(123),l)
    __CONCAT_U__(123)##l
    
    which is not what you want, and gives rise to the (correct)
    warning you see.  You want the argument to be
    expanded, and so you need an extra level of indirection:
    
    #define __CONCAT_INDIRECT(_A,_B) __CONCAT(_A,_B)
    #define __CONCAT__(_A,_B) _A ## _B
    #define __CONCAT_U__(_A) _A ## u
    #define UINT32_C(__c) _CONCAT_INDIRECT__(__CONCAT_U__(__c),l)
    UINT32_C(123)
    
    If HPUX AnsiC gives the answer you wanted, then it's simply
    not ANSI 8-)
    
    Neil.
Comment 5 Andreas Schwab 2002-09-19 15:45:21 UTC 
From: Andreas Schwab <schwab@suse.de>
To: neil@gcc.gnu.org
Cc: gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org,
	stoppel@immt.pwr.wroc.pl, gcc-gnats@gcc.gnu.org
Subject: Re: preprocessor/7976: macro definition
Date: Thu, 19 Sep 2002 15:45:21 +0200

 neil@gcc.gnu.org writes:
 
 |> Synopsis: macro definition
 |> 
 |> State-Changed-From-To: closed->open
 |> State-Changed-By: neil
 |> State-Changed-When: Thu Sep 19 06:13:38 2002
 |> State-Changed-Why:
 |>     Sorry, ignore previous message.  I'll look at this later.
 
 IMHO your previous analysis was right.
 
 UINT32_C(123) ->
 __CONCAT__(__CONCAT_U__(123),l) ->
 __CONCAT_U__(123) ## l
 
 and )l is not a token.  This needs to be written like this:
 
 #define __CONCAT2__(_A,_B) _A ## _B
 #define __CONCAT__(_A,_B) __CONCAT2__(_A,_B)
 #define __CONCAT_U__(_A) _A ## u
 #define UINT32_C(__c) __CONCAT__(__CONCAT_U__(__c),l)
 
 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."
Comment 6 Andrew Pinski 2004-09-02 20:34:02 UTC 
*** Bug 17299 has been marked as a duplicate of this bug. ***
Comment 7 Andrew Pinski 2004-09-02 20:34:40 UTC 
*** Bug 16275 has been marked as a duplicate of this bug. ***
Comment 8 Andrew Pinski 2004-09-02 20:35:34 UTC 
*** Bug 12513 has been marked as a duplicate of this bug. ***
Comment 9 Andrew Pinski 2004-09-02 20:37:16 UTC 
*** Bug 9689 has been marked as a duplicate of this bug. ***
Comment 10 Andrew Pinski 2004-09-02 20:38:14 UTC 
Reopening to mark as ...
Comment 11 Andrew Pinski 2004-09-02 20:38:45 UTC 
Not a bug.
Comment 12 Andrew Pinski 2004-09-03 08:23:08 UTC 
*** Bug 17304 has been marked as a duplicate of this bug. ***
Comment 13 Andrew Pinski 2004-09-03 09:26:38 UTC 
*** Bug 17304 has been marked as a duplicate of this bug. ***
Comment 14 Andrew Pinski 2005-09-28 04:02:17 UTC 
*** Bug 24098 has been marked as a duplicate of this bug. ***
Comment 15 Andrew Pinski 2005-09-28 04:05:01 UTC 
*** Bug 17638 has been marked as a duplicate of this bug. ***
Comment 16 Andrew Pinski 2005-09-28 04:05:34 UTC 
*** Bug 12607 has been marked as a duplicate of this bug. ***
Comment 17 PLANTA 2005-09-28 14:35:29 UTC 
Subject: AW:  macro definition

Stopp blaming us!!!

Remove us immediatelly from cc List.

Thx!


 -----Ursprüngliche Nachricht-----
Von: 	pinskia at gcc dot gnu dot org [mailto:gcc-bugzilla@gcc.gnu.org] 
Gesendet:	Mittwoch, 28. September 2005 06:06
An:	planta
Betreff:	[Bug preprocessor/7976] macro definition


------- Additional Comments From pinskia at gcc dot gnu dot org  2005-09-28 04:05 -------
*** Bug 12607 has been marked as a duplicate of this bug. ***
Comment 18 Diego Novillo 2005-09-28 14:40:09 UTC 
 
As requested in comment #17
Comment 19 Andrew Pinski 2005-11-30 01:33:33 UTC 
*** Bug 25170 has been marked as a duplicate of this bug. ***