Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
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++ ( 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, 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.