public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Change in preprocessor behavior
@ 2022-06-21  0:34 Dave Blanchard
  2022-06-21  7:28 ` Richard Biener
  0 siblings, 1 reply; 12+ messages in thread
From: Dave Blanchard @ 2022-06-21  0:34 UTC (permalink / raw)
  To: gcc

At some point between GCC 9 and GCC 12, the preprocessor started behaving differently. Before if GCC were launched as /lib/cpp or /usr/bin/cpp (I think) it would assume the user wanted to preprocess something and automatically launch in preprocessor mode. Now the behavior has changed and it just acts as the normal compiler. Can someone kindly point me to the patch or commit where this feature was changed, and the rationale for doing so? Thank you.

-- 
Dave Blanchard <dave@killthe.net>

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Change in preprocessor behavior
  2022-06-21  0:34 Change in preprocessor behavior Dave Blanchard
@ 2022-06-21  7:28 ` Richard Biener
  2022-06-21 12:57   ` Dave Blanchard
  0 siblings, 1 reply; 12+ messages in thread
From: Richard Biener @ 2022-06-21  7:28 UTC (permalink / raw)
  To: Dave Blanchard; +Cc: GCC Development

On Tue, Jun 21, 2022 at 2:34 AM Dave Blanchard <dave@killthe.net> wrote:
>
> At some point between GCC 9 and GCC 12, the preprocessor started behaving differently. Before if GCC were launched as /lib/cpp or /usr/bin/cpp (I think) it would assume the user wanted to preprocess something and automatically launch in preprocessor mode. Now the behavior has changed and it just acts as the normal compiler. Can someone kindly point me to the patch or commit where this feature was changed, and the rationale for doing so? Thank you.

It still does that for me.

> ~/install/gcc-12/usr/local/bin/cpp t.c
# 0 "t.c"
# 0 "<built-in>"
# 0 "<command-line>"
...

maybe you can be more specific as to how you invoke 'cpp'.  Did you
build gcc yourself?  What
is the 'cpp' you invoke (is it maybe a script or a symlink?)

Richard.

> --
> Dave Blanchard <dave@killthe.net>

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Change in preprocessor behavior
  2022-06-21  7:28 ` Richard Biener
@ 2022-06-21 12:57   ` Dave Blanchard
  0 siblings, 0 replies; 12+ messages in thread
From: Dave Blanchard @ 2022-06-21 12:57 UTC (permalink / raw)
  To: Richard Biener; +Cc: gcc


On Tue, 21 Jun 2022 09:28:00 +0200
Richard Biener <richard.guenther@gmail.com> wrote:

> On Tue, Jun 21, 2022 at 2:34 AM Dave Blanchard <dave@killthe.net> wrote:
> >
> > At some point between GCC 9 and GCC 12, the preprocessor started behaving differently. Before if GCC were launched as /lib/cpp or /usr/bin/cpp (I think) it would assume the user wanted to preprocess something and automatically launch in preprocessor mode. Now the behavior has changed and it just acts as the normal compiler. Can someone kindly point me to the patch or commit where this feature was changed, and the rationale for doing so? Thank you.
> 
> maybe you can be more specific as to how you invoke 'cpp'.  Did you
> build gcc yourself?  What
> is the 'cpp' you invoke (is it maybe a script or a symlink?)

Oops, it looks like my script had accidentally overwritten 'cpp' with a symlink to gcc. Fixed that and it's working now. Thanks.
 

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Change in preprocessor behavior
  2002-12-30 20:53 Stephen Lindholm
                   ` (2 preceding siblings ...)
  2003-01-02 20:42 ` Mike Stump
@ 2003-01-04 20:19 ` Zack Weinberg
  3 siblings, 0 replies; 12+ messages in thread
From: Zack Weinberg @ 2003-01-04 20:19 UTC (permalink / raw)
  To: Stephen Lindholm; +Cc: gcc

On Mon, Dec 30, 2002 at 02:38:50PM -0800, Stephen Lindholm wrote:
> 
> The stringize and token-pasting operators seem to no longer work in the
> "cpp" phases of compilation, but they worked in "cpp" in early versions of
> gcc (2.95.3). I can't find it written that those operations must occur in
> phases 1-4, but # and ## are "preprocessing-op-or-punc" and it would seem
> that they should therefore be processed in phase 4.

Others have addressed why "cpp" on Mac OS X isn't behaving as you expect;
I would only like to add that "cc -E" or "gcc -E" should do what you want
with all versions of GCC and with a number of other Unix compilers as well.

zw

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Change in preprocessor behavior
  2002-12-30 20:54 ` Neil Booth
  2002-12-30 20:54   ` Stephen Lindholm
@ 2003-01-02 21:04   ` Devang Patel
  1 sibling, 0 replies; 12+ messages in thread
From: Devang Patel @ 2003-01-02 21:04 UTC (permalink / raw)
  To: Neil Booth; +Cc: Devang Patel, Stephen Lindholm, gcc

[-- Attachment #1: Type: text/plain, Size: 439 bytes --]


On Monday, December 30, 2002, at 02:51 PM, Neil Booth wrote:

>
> Stephen Lindholm wrote:-
>
>> thrush:~% cpp test2
>> # 1 "test2"
>>
>>
>> struct command commands[] =
>> {
>>   { #quit, quit ## _command },
>>   { #help, help ## _command },
>> };
>
> Contrary to your claim, I suspect you're using cpp -traditional, no?

I guess yes he is, (but indirectly). In Mac OS X, /usr/bin/cpp is a 
shell
script and it adds -traditional.

-Devang

[-- Attachment #2: Type: text/enriched, Size: 493 bytes --]



On Monday, December 30, 2002, at 02:51 PM, Neil Booth wrote:


<excerpt>

<fixed>Stephen Lindholm wrote:-


<excerpt>thrush:~% cpp test2

# 1 "test2"



struct command commands[] =

{

  { #quit, quit ## _command },

  { #help, help ## _command },

};

</excerpt>

Contrary to your claim, I suspect you're using cpp -traditional, no?

</fixed></excerpt><fixed>

I guess yes he is, (but indirectly). In Mac OS X, /usr/bin/cpp is a
shell 

script and it adds -traditional.

</fixed>

-Devang


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Change in preprocessor behavior
  2003-01-02 20:42 ` Mike Stump
@ 2003-01-02 21:02   ` Devang Patel
  0 siblings, 0 replies; 12+ messages in thread
From: Devang Patel @ 2003-01-02 21:02 UTC (permalink / raw)
  To: Mike Stump; +Cc: Devang Patel, Stephen Lindholm, gcc

[-- Attachment #1: Type: text/plain, Size: 2442 bytes --]


On Thursday, January 2, 2003, at 12:42 PM, Mike Stump wrote:

[snip]
> I cannot explain why.  My best guess is that you are not using 1175, 
> or that you didn't use gcc_select to select gcc3.  What does 
> gcc_select say when you run it?

I guess, it's because of /usr/bin/cpp.

On Mac OS X, /usr/bin/cpp is a shell script. It messages few arguments 
and then invokes GCC cpp. Comments in that shell script says ...
"
...
# Transitional front end to CCCP to make it behave like (Reiser) CCP:
#       specifies -traditional
#       doesn't search gcc-include
#
# Please beware that this program exists only to provide legacy BSD
#    software access to cccp. Direct access to the C pre-processor
#    is deprecated; it is only supported for use by the cc(1) C
#    compiler. Use of cccp for anything other than C code is a bad
#    idea. Don't do it. If you want a macro processor, use m4(1).
#
...
"
:-)

And
"cpp -v test2.c" says

Reading specs from /usr/libexec/gcc/darwin/ppc/3.1/specs
Thread model: posix
Apple Computer, Inc. GCC version 1175, based on gcc version 3.1 
20020420 (prerelease)
  /usr/libexec/gcc/darwin/ppc/3.1/tradcpp0 -lang-c -v -$ -iprefix 
/usr/libexec/gcc/darwin/ppc/default/../libexec/gcc/darwin/ppc/3.1/ 
-DMAC_OS_X_VERSION_MIN_REQUIRED=1020 -D__ppc__ -D__POWERPC__ 
-D__NATURAL_ALIGNMENT__ -D__MACH__ -D__BIG_ENDIAN__ -D__APPLE__ 
-D__ppc__ -D__POWERPC__ -D__NATURAL_ALIGNMENT__ -D__MACH__ 
-D__BIG_ENDIAN__ -D__APPLE__ -D__NO_INLINE__ -D__STDC_HOSTED__=1 
-D__DYNAMIC__ -D__GNUC__ -D__CONSTANT_CFSTRINGS__ test2.c
GNU traditional CPP version 3.1 20020420 (prerelease)
...

where as "cpp -v test2.cc" says

Reading specs from /usr/libexec/gcc/darwin/ppc/3.1/specs
Thread model: posix
Apple Computer, Inc. GCC version 1175, based on gcc version 3.1 
20020420 (prerelease)
  /usr/libexec/gcc/darwin/ppc/3.1/cpp0 -lang-c++ -D__DEPRECATED 
-D__EXCEPTIONS -D__GXX_ABI_VERSION=100 -v -$ -iprefix 
/usr/libexec/gcc/darwin/ppc/default/../libexec/gcc/darwin/ppc/3.1/ 
-DMAC_OS_X_VERSION_MIN_REQUIRED=1020 -D__ppc__ -D__POWERPC__ 
-D__NATURAL_ALIGNMENT__ -D__MACH__ -D__BIG_ENDIAN__ -D__APPLE__ 
-D__ppc__ -D__POWERPC__ -D__NATURAL_ALIGNMENT__ -D__MACH__ 
-D__BIG_ENDIAN__ -D__APPLE__ -D__NO_INLINE__ -D__STDC_HOSTED__=1 
-D__DYNAMIC__ -D__GNUC__ -D__CONSTANT_CFSTRINGS__ test2.cc
GNU CPP version 3.1 20020420 (prerelease) (cpplib) (Darwin/PowerPC)
....

(On Mac OS X, /usr/bin/cpp is not part of system compiler)

-Devang

[-- Attachment #2: Type: text/enriched, Size: 2505 bytes --]



On Thursday, January 2, 2003, at 12:42 PM, Mike Stump wrote:


[snip]

<excerpt><fixed>I cannot explain why.  My best guess is that you are
not using 1175, or that you didn't use gcc_select to select gcc3. 
What does gcc_select say when you run it?

</fixed></excerpt><fixed>

I guess, it's because of /usr/bin/cpp.


On Mac OS X, /usr/bin/cpp is a shell script. It messages few arguments
and then invokes GCC cpp. Comments in that shell script says ...

"

...

# Transitional front end to CCCP to make it behave like (Reiser) CCP:

#       specifies -traditional

#       doesn't search gcc-include

#

# Please beware that this program exists only to provide legacy BSD

#    software access to cccp. Direct access to the C pre-processor

#    is deprecated; it is only supported for use by the cc(1) C

#    compiler. Use of cccp for anything other than C code is a bad

#    idea. Don't do it. If you want a macro processor, use m4(1).

#

...

"

:-)


And

"cpp -v test2.c" says


Reading specs from /usr/libexec/gcc/darwin/ppc/3.1/specs

Thread model: posix

Apple Computer, Inc. GCC version 1175, based on gcc version 3.1
20020420 (prerelease)

 /usr/libexec/gcc/darwin/ppc/3.1/tradcpp0 -lang-c -v -$ -iprefix
/usr/libexec/gcc/darwin/ppc/default/../libexec/gcc/darwin/ppc/3.1/
-DMAC_OS_X_VERSION_MIN_REQUIRED=1020 -D__ppc__ -D__POWERPC__
-D__NATURAL_ALIGNMENT__ -D__MACH__ -D__BIG_ENDIAN__ -D__APPLE__
-D__ppc__ -D__POWERPC__ -D__NATURAL_ALIGNMENT__ -D__MACH__
-D__BIG_ENDIAN__ -D__APPLE__ -D__NO_INLINE__ -D__STDC_HOSTED__=1
-D__DYNAMIC__ -D__GNUC__ -D__CONSTANT_CFSTRINGS__ test2.c

GNU traditional CPP version 3.1 20020420 (prerelease)

...


where as "cpp -v test2.cc" says

</fixed>

Reading specs from /usr/libexec/gcc/darwin/ppc/3.1/specs

Thread model: posix

Apple Computer, Inc. GCC version 1175, based on gcc version 3.1
20020420 (prerelease)

 /usr/libexec/gcc/darwin/ppc/3.1/cpp0 -lang-c++ -D__DEPRECATED
-D__EXCEPTIONS -D__GXX_ABI_VERSION=100 -v -$ -iprefix
/usr/libexec/gcc/darwin/ppc/default/../libexec/gcc/darwin/ppc/3.1/
-DMAC_OS_X_VERSION_MIN_REQUIRED=1020 -D__ppc__ -D__POWERPC__
-D__NATURAL_ALIGNMENT__ -D__MACH__ -D__BIG_ENDIAN__ -D__APPLE__
-D__ppc__ -D__POWERPC__ -D__NATURAL_ALIGNMENT__ -D__MACH__
-D__BIG_ENDIAN__ -D__APPLE__ -D__NO_INLINE__ -D__STDC_HOSTED__=1
-D__DYNAMIC__ -D__GNUC__ -D__CONSTANT_CFSTRINGS__ test2.cc

GNU CPP version 3.1 20020420 (prerelease) (cpplib) (Darwin/PowerPC)

....


(On Mac OS X, /usr/bin/cpp is not part of system compiler)


-Devang


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Change in preprocessor behavior
  2002-12-30 20:53 Stephen Lindholm
  2002-12-30 20:54 ` Neil Booth
  2002-12-30 20:54 ` Neil Booth
@ 2003-01-02 20:42 ` Mike Stump
  2003-01-02 21:02   ` Devang Patel
  2003-01-04 20:19 ` Zack Weinberg
  3 siblings, 1 reply; 12+ messages in thread
From: Mike Stump @ 2003-01-02 20:42 UTC (permalink / raw)
  To: Stephen Lindholm; +Cc: gcc

On Monday, December 30, 2002, at 02:38 PM, Stephen Lindholm wrote:
> The stringize and token-pasting operators seem to no longer work in the
> "cpp" phases of compilation, but they worked in "cpp" in early  
> versions of
> gcc (2.95.3). I can't find it written that those operations must occur  
> in
> phases 1-4, but # and ## are "preprocessing-op-or-punc" and it would  
> seem
> that they should therefore be processed in phase 4.
>
> Am I doing something wrong?
>
>
> Using this example from the cpp info page:
>
> #define COMMAND(NAME)  { #NAME, NAME ## _command }
>
> struct command commands[] =
> {
>   COMMAND (quit),
>   COMMAND (help),
> };
>
> I get this as expected on an old version of cpp (2.95.3):
>
> Xenon > cpp test2
> # 1 "test2"
>
>
> struct command commands[] =
> {
>   { "quit",  quit_command } ,
>   { "help",  help_command } ,
> };
>
> and this on a new version of cpp (3.1):
>
> thrush:~% cpp test2
> # 1 "test2"
>
>
> struct command commands[] =
> {
>   { #quit, quit ## _command },
>   { #help, help ## _command },
> };

My experience differs from yours:

bash-2.05a$ cat b.cc
#define COMMAND(NAME)  { #NAME, NAME ## _command }

struct command commands[] =
{
   COMMAND (quit),
   COMMAND (help),
};
bash-2.05a$ gcc -v -E b.cc
Reading specs from /usr/libexec/gcc/darwin/ppc/3.1/specs
Thread model: posix
Apple Computer, Inc. GCC version 1175, based on gcc version 3.1  
20020420 (prerelease)
  /usr/libexec/gcc/darwin/ppc/3.1/cpp0 -lang-c++ -D__GNUG__=3  
-D__DEPRECATED -D__EXCEPTIONS -D__GXX_ABI_VERSION=100 -v -D__GNUC__=3  
-D__GNUC_MINOR__=1 -D__GNUC_PATCHLEVEL__=0 -D__APPLE_CC__=1175  
-D__ppc__ -D__POWERPC__ -D__NATURAL_ALIGNMENT__ -D__MACH__  
-D__BIG_ENDIAN__ -D__APPLE__ -D__ppc__ -D__POWERPC__  
-D__NATURAL_ALIGNMENT__ -D__MACH__ -D__BIG_ENDIAN__ -D__APPLE__  
-D__NO_INLINE__ -D__STDC_HOSTED__=1 -D__DYNAMIC__ b.cc
GNU CPP version 3.1 20020420 (prerelease) (cpplib) (Darwin/PowerPC)
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory  
"/usr/lib/gcc-lib/ppc-darwin/3.1/../../../../ppc-darwin/include"
ignoring nonexistent directory "/Local/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
  /usr/include/gcc/darwin/3.1/g++-v3
  /usr/include/gcc/darwin/3.1/g++-v3/ppc-darwin
  /usr/include/gcc/darwin/3.1/g++-v3/backward
  /usr/include/gcc/darwin/3.1
  /usr/include
End of search list.
Framework search starts here:
  /System/Library/Frameworks
  /Library/Frameworks
End of framework search list.
# 1 "b.cc"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "b.cc"


struct command commands[] =
{
   { "quit", quit_command },
   { "help", help_command },
};

and

bash-2.05a$ cpp -v b.cc
Reading specs from /usr/libexec/gcc/darwin/ppc/3.1/specs
Thread model: posix
Apple Computer, Inc. GCC version 1175, based on gcc version 3.1  
20020420 (prerelease)
  /usr/libexec/gcc/darwin/ppc/3.1/cpp0 -lang-c++ -D__DEPRECATED  
-D__EXCEPTIONS -D__GXX_ABI_VERSION=100 -v -$ -iprefix  
/usr/libexec/gcc/darwin/ppc/default/../libexec/gcc/darwin/ppc/3.1/  
-D__ppc__ -D__POWERPC__ -D__NATURAL_ALIGNMENT__ -D__MACH__  
-D__BIG_ENDIAN__ -D__APPLE__ -D__ppc__ -D__POWERPC__  
-D__NATURAL_ALIGNMENT__ -D__MACH__ -D__BIG_ENDIAN__ -D__APPLE__  
-D__NO_INLINE__ -D__STDC_HOSTED__=1 -D__DYNAMIC__ -D__GNUC__ b.cc
GNU CPP version 3.1 20020420 (prerelease) (cpplib) (Darwin/PowerPC)
ignoring nonexistent directory  
"/usr/libexec/gcc/darwin/ppc/default/../libexec/gcc/darwin/ppc/3.1/+-v3"
ignoring nonexistent directory  
"/usr/libexec/gcc/darwin/ppc/default/../libexec/gcc/darwin/ppc/3.1/+- 
v3/ppc-darwin"
ignoring nonexistent directory  
"/usr/libexec/gcc/darwin/ppc/default/../libexec/gcc/darwin/ppc/3.1/+- 
v3/backward"
ignoring nonexistent directory  
"/usr/libexec/gcc/darwin/ppc/default/../libexec/gcc/darwin/ppc/3.1/+- 
v3/.."
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory  
"/usr/lib/gcc-lib/ppc-darwin/3.1/../../../../ppc-darwin/include"
ignoring nonexistent directory "/Local/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
  /usr/include/gcc/darwin/3.1/g++-v3
  /usr/include/gcc/darwin/3.1/g++-v3/ppc-darwin
  /usr/include/gcc/darwin/3.1/g++-v3/backward
  /usr/include/gcc/darwin/3.1
  /usr/include
End of search list.
Framework search starts here:
  /System/Library/Frameworks
  /Library/Frameworks
End of framework search list.
# 1 "b.cc"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "b.cc"


struct command commands[] =
{
   { "quit", quit_command },
   { "help", help_command },
};

I cannot explain why.  My best guess is that you are not using 1175, or  
that you didn't use gcc_select to select gcc3.  What does gcc_select  
say when you run it?

^ permalink raw reply	[flat|nested] 12+ messages in thread

* RE: Change in preprocessor behavior
@ 2002-12-31 10:24 Martin York
  0 siblings, 0 replies; 12+ messages in thread
From: Martin York @ 2002-12-31 10:24 UTC (permalink / raw)
  To: 'Stephen Lindholm', Neil Booth; +Cc: gcc



I may be wrong (I don't have a machine close by with gcc on).

Try adding the -v flag to your compile.
This shows all the flags passed to the underlying frontend (cc1plus)


Then you can compare the flags used on Solaris and OS-X.

You will then be able to see if -traditional is being passed
to cc1plus on your OS-X machine



I also believe you can override the flags passed to the frontend
by specifying a specs file on the command line (though I have never
tried this myself). This may be simpler then rebuilding gcc.


Martin.

-----Original Message-----
From: Stephen Lindholm [mailto:lindholm@CS.Stanford.EDU]
Sent: 30 December 2002 18:46
To: Neil Booth
Cc: gcc@gcc.gnu.org
Subject: Re: Change in preprocessor behavior



I'm using the version of gcc which came with Mac OS X, and I compared it
to the old version of gcc installed on the Solaris mail server. I did not
install either of the two compilers myself.

I did cut and paste the command line and output exactly as they were in
the terminal window.

I guess the OS X compiler came out of the box configured differently than
I expected. I know it has some modifications to support Mac programming,
but I did not expect the preprocessor to be configured differently. I
guess I will just have to use a different computer for my preprocessing or
install another version of gcc.

Thank you for your help.


On Mon, 30 Dec 2002, Neil Booth wrote:

> Stephen Lindholm wrote:-
> 
> > thrush:~% cpp test2
> > # 1 "test2"
> > 
> >       
> > struct command commands[] =
> > {
> >   { #quit, quit ## _command },
> >   { #help, help ## _command },
> > };
> 
> Contrary to your claim, I suspect you're using cpp -traditional, no?
> 
> Traditional preprocessors did not support # and ##, and 3.1 is more
> "correct" in this respect.  FWIW 3.3 has another new implementation of
> traditional preprocessing which is the most faithful of GCC's
> implementations to true traditional preprocessing.
> 
> Neil.
> 

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Change in preprocessor behavior
  2002-12-30 20:54 ` Neil Booth
@ 2002-12-30 20:54   ` Stephen Lindholm
  2003-01-02 21:04   ` Devang Patel
  1 sibling, 0 replies; 12+ messages in thread
From: Stephen Lindholm @ 2002-12-30 20:54 UTC (permalink / raw)
  To: Neil Booth; +Cc: gcc


I'm using the version of gcc which came with Mac OS X, and I compared it
to the old version of gcc installed on the Solaris mail server. I did not
install either of the two compilers myself.

I did cut and paste the command line and output exactly as they were in
the terminal window.

I guess the OS X compiler came out of the box configured differently than
I expected. I know it has some modifications to support Mac programming,
but I did not expect the preprocessor to be configured differently. I
guess I will just have to use a different computer for my preprocessing or
install another version of gcc.

Thank you for your help.


On Mon, 30 Dec 2002, Neil Booth wrote:

> Stephen Lindholm wrote:-
> 
> > thrush:~% cpp test2
> > # 1 "test2"
> > 
> >       
> > struct command commands[] =
> > {
> >   { #quit, quit ## _command },
> >   { #help, help ## _command },
> > };
> 
> Contrary to your claim, I suspect you're using cpp -traditional, no?
> 
> Traditional preprocessors did not support # and ##, and 3.1 is more
> "correct" in this respect.  FWIW 3.3 has another new implementation of
> traditional preprocessing which is the most faithful of GCC's
> implementations to true traditional preprocessing.
> 
> Neil.
> 

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Change in preprocessor behavior
  2002-12-30 20:53 Stephen Lindholm
@ 2002-12-30 20:54 ` Neil Booth
  2002-12-30 20:54 ` Neil Booth
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 12+ messages in thread
From: Neil Booth @ 2002-12-30 20:54 UTC (permalink / raw)
  To: Stephen Lindholm; +Cc: gcc

Stephen Lindholm wrote:-

> Am I doing something wrong?
> 
> Using this example from the cpp info page:
> 
> #define COMMAND(NAME)  { #NAME, NAME ## _command }
>       
> struct command commands[] =
> {
>   COMMAND (quit),
>   COMMAND (help),
> };
> 
> I get this as expected on an old version of cpp (2.95.3):
> 
> Xenon > cpp test2
> # 1 "test2"
> 
>       
> struct command commands[] =
> {
>   { "quit",  quit_command } ,
>   { "help",  help_command } ,
> };
> 
> and this on a new version of cpp (3.1):
> 
> thrush:~% cpp test2
> # 1 "test2"
> 
>       
> struct command commands[] =
> {
>   { #quit, quit ## _command },
>   { #help, help ## _command },
> };
 
I can't reproduce this.  In fact, I don't believe you're using GCC 3.1,
since the output would be more like that below (note the <built-in>
etc.).

FWIW I am confident there are no bugs in # and ## handling in GCC 3.1
and later.

Neil.
 

$ cpp --version
cpp (GCC) 3.1.1 20020721 (prerelease)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

$ cpp /tmp/bug.c
# 1 "/tmp/bug.c"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "/tmp/bug.c"


struct command commands[] =
{
  { "quit", quit_command },
  { "help", help_command },
};
$

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Change in preprocessor behavior
  2002-12-30 20:53 Stephen Lindholm
  2002-12-30 20:54 ` Neil Booth
@ 2002-12-30 20:54 ` Neil Booth
  2002-12-30 20:54   ` Stephen Lindholm
  2003-01-02 21:04   ` Devang Patel
  2003-01-02 20:42 ` Mike Stump
  2003-01-04 20:19 ` Zack Weinberg
  3 siblings, 2 replies; 12+ messages in thread
From: Neil Booth @ 2002-12-30 20:54 UTC (permalink / raw)
  To: Stephen Lindholm; +Cc: gcc

Stephen Lindholm wrote:-

> thrush:~% cpp test2
> # 1 "test2"
> 
>       
> struct command commands[] =
> {
>   { #quit, quit ## _command },
>   { #help, help ## _command },
> };

Contrary to your claim, I suspect you're using cpp -traditional, no?

Traditional preprocessors did not support # and ##, and 3.1 is more
"correct" in this respect.  FWIW 3.3 has another new implementation of
traditional preprocessing which is the most faithful of GCC's
implementations to true traditional preprocessing.

Neil.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Change in preprocessor behavior
@ 2002-12-30 20:53 Stephen Lindholm
  2002-12-30 20:54 ` Neil Booth
                   ` (3 more replies)
  0 siblings, 4 replies; 12+ messages in thread
From: Stephen Lindholm @ 2002-12-30 20:53 UTC (permalink / raw)
  To: gcc


The stringize and token-pasting operators seem to no longer work in the
"cpp" phases of compilation, but they worked in "cpp" in early versions of
gcc (2.95.3). I can't find it written that those operations must occur in
phases 1-4, but # and ## are "preprocessing-op-or-punc" and it would seem
that they should therefore be processed in phase 4.

Am I doing something wrong?


Using this example from the cpp info page:

#define COMMAND(NAME)  { #NAME, NAME ## _command }
      
struct command commands[] =
{
  COMMAND (quit),
  COMMAND (help),
};

I get this as expected on an old version of cpp (2.95.3):

Xenon > cpp test2
# 1 "test2"

      
struct command commands[] =
{
  { "quit",  quit_command } ,
  { "help",  help_command } ,
};

and this on a new version of cpp (3.1):

thrush:~% cpp test2
# 1 "test2"

      
struct command commands[] =
{
  { #quit, quit ## _command },
  { #help, help ## _command },
};


^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2022-06-21 12:56 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-21  0:34 Change in preprocessor behavior Dave Blanchard
2022-06-21  7:28 ` Richard Biener
2022-06-21 12:57   ` Dave Blanchard
  -- strict thread matches above, loose matches on Subject: below --
2002-12-31 10:24 Martin York
2002-12-30 20:53 Stephen Lindholm
2002-12-30 20:54 ` Neil Booth
2002-12-30 20:54 ` Neil Booth
2002-12-30 20:54   ` Stephen Lindholm
2003-01-02 21:04   ` Devang Patel
2003-01-02 20:42 ` Mike Stump
2003-01-02 21:02   ` Devang Patel
2003-01-04 20:19 ` Zack Weinberg

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).