Bug 80177 - GCC accepts erroneous code due to wayward object construction/typecasting
GCC accepts erroneous code due to wayward object construction/typecasting
Product: Red Hat Linux
Classification: Retired
Component: gcc3 (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Depends On:
  Show dependency treegraph
Reported: 2002-12-21 03:18 EST by Sysoltsev Slawa
Modified: 2007-04-18 12:49 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-03 07:13:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Sysoltsev Slawa 2002-12-21 03:18:31 EST
Description of problem:
compiling such test case:
struct  QCString
    QCString( int size ) {};
    QCString( const char *str ) {};

inline bool operator==( const QCString &s1, const QCString &s2 )
{ return 0; }

enum EStyle

static EStyle   getFillStyle() { return FS_SOLID; }

int main()
    if(getFillStyle() == "FS_SOLID") {}; // error here, FS_SOLID, 
not "FS_SOLID" must be

with command line: `g++ test.c`
GNU C++ compiler accepts the test case without any warnings!
Comparing 'enum EStyle' and 'char *' it IMPLICITLY casts enum to int, then int 
to QCString, from other side IMPLICITLY casts 'char *' to QCString and finally 
compares these using ‘inline bool operator==( const QCString &s1, const 
QCString &s2 )’ operator. That's incredible! Too much flexibility is used here; 
therefore erroneous code passed "strict" C++ checking. As a result hard-to-find 
run-time error will be.

This test case was distilled from koffice application from Red Hat 8.0 Linux 
C++ compiler should do stricter checking. In this test case it should emit 
error about incomparable types.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. g++ test.cc (test.cc is in description)

Actual results:
Succesfully compiled ill-formed code.

Expected results:
Compilation error.

Additional info:
Comment 1 Alexandre Oliva 2003-05-11 17:08:32 EDT
Since one of the operands of == is a class or enumerated type []/1,
user-defined operators are candidate functions.  However, to avoid the very kind
of error you've observed, paragraph 3 of the same clause, that defines how the
candidate functions are selected, says, in the second bullet:
   [...] if no operand has a class type, only those non-
    member functions in the lookup set that have a  first  parameter  of
    type  T1 or "reference to (possibly cv-qualified) T1", when T1 is an
    enumeration type, or (if there is a right operand) a second  parame-
    ter of type T2 or "reference to (possibly cv-qualified) T2", when T2
    is an enumeration type, are candidate functions.
So this is a bug, indeed.  However, I strongly recommend reporting this in the
bug tracking system at gcc.gnu.org, instead of here.
Comment 2 Richard Henderson 2004-10-03 07:13:10 EDT
Problem persists through gcc 4.0.  Pushed upstream to

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