Bug 22324 - preprocessing does not ignore c++ operator keywords (xor)
preprocessing does not ignore c++ operator keywords (xor)
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: gcc (Show other bugs)
7.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-12-14 22:07 EST by j. alan eldridge
Modified: 2007-04-18 12:30 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-01-31 02:58:52 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description j. alan eldridge 2000-12-14 22:07:13 EST
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 05:58:37 EST
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 10:51:34 EST
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-19 21:21:15 EST
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-19 21:25:34 EST
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 03:45:26 EST
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 02:58:49 EST
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 05:06:02 EST
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.