Red Hat Bugzilla – Bug 149098
bogus function declaration conflict in C++
Last modified: 2013-07-02 23:03:52 EDT
Description of problem: $ cat tgl.c extern "C" void std::exit (int) throw (); using std::exit; #include <stdlib.h> $ g++ -c tgl.c /usr/include/stdlib.h:644: error: `void exit(int)' conflicts with previous using declaration `void std::exit(int)' /usr/include/stdlib.h:644: error: `void exit(int)' conflicts with used function tgl.c:1: error: `void std::exit(int)' previously declared here I might have thought this was ok, except (a) if I include stdlib.h first then g++ accepts this, and (b) g++ 3.4.2 accepts either order. Version-Release number of selected component (if applicable): gcc-c++-3.4.3-19 How reproducible: 100% Steps to Reproduce: 1. See above 2. 3. Actual results: Failure depends on declaration ordering. Expected results: No failure ... or consistent failure. Your choice. Additional info: This breaks most autoconf c++ tests that involve stdlib.h, because autoconf is cavalier about which order the lines appear in; it tests for the right way to declare exit() in the order that works, but then puts the declaration ahead of stdlib.h when it counts. In particular I'm dead in the water with respect to rebuilding mysql in rawhide, so I'd appreciate a fix ASAP.
I forgot to mention that the same thing is happening in gcc4; or at least, the test build Karsten did yesterday showed mysql failing in the same way as I now see in rawhide.
Simplified into: extern "C" void exit (int) throw (); extern "C" void std::exit (int) throw (); using std::exit; which works and extern "C" void std::exit (int) throw (); using std::exit; extern "C" void exit (int) throw (); which doesn't in neither g++4 nor quite recent 3.4.3-RH (works with 20050113 but doesn't with 20050209. Don't know whether that is a bug or mandated behaviour by the standard though.
One would like to think that the standard is better designed than that :-( A possible solution if it's determined that gcc is actually operating as designed is to hack up autoconf so that it always emits the explicit declaration before including stdlib.h. If you think this will take awhile to resolve then I shall go bother whoever owns autoconf.
Per the ISO C++ 90 Standard, both cases should be errors, from 7.3.3: 11. If a function declaration in namespace scope or block scope has the same name and the same parameter types as a function introduced by a using-declaration, the program is ill-formed. An example follows in which a function is declared after a using decl, noting that it's ill-formed. It's not entirely clear that having the using decl after the function decl should trigger an error as well, although it appears to be the intent, especially given the discussion regarding DR101: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#101 The resolution is that extern "C" functions can have multiple such declarations, so we should accept, and not reject, both cases. I'll try to cobble up a patch to get the same behavior regardless of the relative location of the using declaration and the possibly-conflicting function definition, without rejecting possibly-conflicting using declarations too early.
You probably know that this is still broken in gcc 4.0.0-0.30, which means I'm still dead in the water for rebuilding mysql.
Should be fixed in gcc-4.0.0-0.32.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2005-257.html