Bug 22324 - preprocessing does not ignore c++ operator keywords (xor)
Summary: preprocessing does not ignore c++ operator keywords (xor)
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gcc
Version: 7.0
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: David Lawrence
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-12-15 03:07 UTC by j. alan eldridge
Modified: 2007-04-18 16:30 UTC (History)
0 users

(edit)
Clone Of:
(edit)
Last Closed: 2001-01-31 07:58:52 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2000:132 normal SHIPPED_LIVE Bug fixing update of GCC 2.96 2000-12-19 05:00:00 UTC

Description j. alan eldridge 2000-12-15 03:07:13 UTC
g++ -fno-operator-names does not cause preprocessing to ignore operator
names. note that since -fno-operator-names is the default, we could just
say the c++ preprocessing can not be made to ignore operator names.

cat >x.cc <<EOF
#ifdef xor
#error xor defined
#endif
#if defined(xor)
#error xor defined too
#endif
EOF

[alane@wozzle /tmp]$ g++ -fno-operator-names -c x.cc
x.cc:1:8: warning: #ifdef with invalid argument
x.cc:4:13: "defined" without an identifier

note that the second one is an *error*. this causes the qt-1.45 include
files as shipped with RH7.0 to not compile. (how did redhat compile
packages that use qt-1.45, or were the binaries not compiled with the same
compiler that shipped?)

Comment 1 Jakub Jelinek 2000-12-15 10:58:37 UTC
We compiled qt 1.45 and KDE1 stuff with the compatibility compiler (egcs++),
because there were tons of other issues with its source. We worked on getting
all the fixes into KDE2 though (that's why KDE2 builds fine with g++).
As for -fno-operator-names, the preprocessor really does not even take
that option nor use it. I've posted a patch for this to gcc-patches today,
will see what the reaction will be (the other alternative would be IMHO
removing -fno-operator-names altogether).

Comment 2 Jakub Jelinek 2000-12-15 15:51:34 UTC
Ok, patch was approved, so it is now in CVS gcc and will appear in the next
gcc rpm build (ie. 2.96-69 whenever it is built).

Comment 3 j. alan eldridge 2000-12-20 02:21:15 UTC
just got 2.96-69. patch does not fix bug. patch introduces two new bugs,
however: 

1. cpp now accepts -fno-operator-names, but it's not the default. however, it
*is* the default for cc1plus. 

2. (MAJOR PROBLEM) -fno-operator-names to cpp disables cpp's builtin operators,
like defined. net effect, -fno-operator-names cannot be specified to gcc anymore
without breaking existing, legal code that used to compile.

demonstration here:
 
[alane@wozzle tmp]$ cat foo.cc
#define xor xor1
#if defined(xor)
#error xor defined
#endif
#ifdef xor
#error ifdef xor
#endif
[alane@wozzle tmp]$ gcc -E foo.cc
# 1 "foo.cc"
foo.cc:1:9: "xor" cannot be used as a macro name in C++
foo.cc:2:13: "defined" without an identifier
foo.cc:5:8: warning: #ifdef with invalid argument
[alane@wozzle tmp]$ gcc -E -fno-operator-names foo.cc
# 1 "foo.cc"
foo.cc:2:12: missing binary operator before '('
foo.cc:6:2: #error ifdef xor
[alane@wozzle tmp]$ cpp -E -fno-operator-names foo.cc
# 1 "foo.cc"
foo.cc:2:12: missing binary operator before '('
foo.cc:6:2: #error ifdef xor
[alane@wozzle tmp]$ cpp -E -foperator-names foo.cc
# 1 "foo.cc"
foo.cc:1:9: "xor" cannot be used as a macro name in C++
foo.cc:2:13: "defined" without an identifier
foo.cc:5:8: warning: #ifdef with invalid argument
[alane@wozzle tmp]$ 

***NOTE*** code that does not use an operator name now will not preprocess
with -fno-operator-names.

[alane@wozzle tmp]$ cat foo.cc
#if defined(rr)
#error rr defined
#endif
[alane@wozzle tmp]$ cpp -E -fno-operator-names foo.cc
# 1 "foo.cc"
foo.cc:1:12: missing binary operator before '('
[alane@wozzle tmp]$ cpp -E  foo.cc
# 1 "foo.cc"
[alane@wozzle tmp]$ 

The only operators that need to be uninterpreted are the ones that are used by
the compiler; that is: and, bitand, bitor, compl, not, or, xor.



Comment 4 j. alan eldridge 2000-12-20 02:25:34 UTC
let me clarify:

cpp needs to accept -foperator-names. this causes it to behave as it does now.
cpp needs to accept -fno-operator-names. this causes it to ignore "and",
"bitand", "bitor", "compl", "not", "or", "xor".

the default is -fno-operator-names.

Comment 5 Jakub Jelinek 2000-12-20 08:45:26 UTC
Doh, you're right. I coded and tested the patch for mainline CVS, where
-foperator-names is the default and defined is handled in a different way.
I now have a fix for this in my tree, basically cpp0 now accepts
both -f{,no-}operator-names, defaults to no-operator-names
and `defined' is added to the list of built-in operators
no matter what -f option was given.
This will appear in 2.96-70.

Comment 6 j. alan eldridge 2001-01-31 07:58:49 UTC
is there any hope yet for a fixed version of cpp? since the patch did leave
things worse off in 2.96-69, it would be nice to have a 2.96-70 sometime soon,
just to bring things back to working
again. sorry to harp on this, but releasing a completely untested patch that
breaks working programs and then not releasing the correct fix is annoying.

Comment 7 Jakub Jelinek 2001-01-31 10:06:02 UTC
This is fixed in rawhide for ages, I just apparently forgot to close this bug.
There is no official errata update yet because I want to add some more fixes
first.


Note You need to log in before you can comment on or make changes to this bug.