Bug 80177 - GCC accepts erroneous code due to wayward object construction/typecasting
Summary: GCC accepts erroneous code due to wayward object construction/typecasting
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gcc3
Version: 8.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2002-12-21 08:18 UTC by Sysoltsev Slawa
Modified: 2007-04-18 16:49 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-10-03 11:13:10 UTC

Attachments (Terms of Use)

Description Sysoltsev Slawa 2002-12-21 08:18:31 UTC
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 21:08:32 UTC
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 11:13:10 UTC
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.