public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* preprocessor/5240: Unicode L## doesn't work in all cases for macros
@ 2002-01-02 0:56 dstarr
0 siblings, 0 replies; 2+ messages in thread
From: dstarr @ 2002-01-02 0:56 UTC (permalink / raw)
To: gcc-gnats
>Number: 5240
>Category: preprocessor
>Synopsis: Unicode L## doesn't work in all cases for macros
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: unassigned
>State: open
>Class: ice-on-legal-code
>Submitter-Id: net
>Arrival-Date: Wed Jan 02 00:56:00 PST 2002
>Closed-Date:
>Last-Modified:
>Originator: dstarr@opera.com
>Release: versions 3.0 and later
>Organization:
>Environment:
All
>Description:
This is best described by first looking at the code.
When using the code which is listed in the How-To-Repeat section, a compiler error occurs stating that LMyTestString was not declared.
This to me makes it seam that the preprocessor is expanding UNI_L(MyTestString) to LMyTestString instead of L##MyTestString.
I'm not 100% sure that this is perfectly valid code, however MSVC, CodeWarrior, Intel (list goes on a long while) all handle this code as intended.
>How-To-Repeat:
#define UNI_L(string) L##string
#define MyTestString "Hello World!"
int main(int argc, char **argv)
{
...
CallToUnicodeFunction(UNI_L(MyTestString));
...
}
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: preprocessor/5240: Unicode L## doesn't work in all cases for macros
@ 2002-01-02 1:40 neil
0 siblings, 0 replies; 2+ messages in thread
From: neil @ 2002-01-02 1:40 UTC (permalink / raw)
To: dstarr, gcc-bugs, gcc-prs, nobody
Synopsis: Unicode L## doesn't work in all cases for macros
State-Changed-From-To: open->closed
State-Changed-By: neil
State-Changed-When: Wed Jan 2 01:40:47 2002
State-Changed-Why:
Not a bug - GCC is correct.
The standard states that arguments are expanded, UNLESS the parameter is preceded by a # or ##, or followed by a ##. Your parameter is preceded by a ##.
I find it *very* hard to believe that other compilers get it wrong. In particular, Intel uses the EDG front end. Comeau also uses the EDG front end, and if you go to
http://www.comeaucomputing.com/tryitout/
and give the on-line compiler your input, with a command line of -E, the output you will get is
int main(int argc, char **argv)
{
...
CallToUnicodeFunction(LMyTestString);
...
}
which is what GCC is giving.
It is possible that all the compilers you list other than MSVC have a work-around for MSVC brokenness when on Windows, but I doubt it because even selecting WindowsNT on the Comeau home page doesn't affect the result. Maybe it requires an --enable-brokenness flag of some kind. *shrug*.
To get the result you want, you need to have an extra level of indirection so that the argument is expanded according to the rule I give above:
#define UNI_L2(string) L##string
#define UNI_L(string) UNI_L2(string)
#define MyTestString "Hello World!"
CallToUnicodeFunction(UNI_L(MyTestString));
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5240
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2002-01-02 9:40 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-01-02 0:56 preprocessor/5240: Unicode L## doesn't work in all cases for macros dstarr
2002-01-02 1:40 neil
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).