This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/11390] line directives interfere with friend linkage
- From: "ehrhardt at mathematik dot uni-ulm dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 3 Jul 2003 09:32:08 -0000
- Subject: [Bug c++/11390] line directives interfere with friend linkage
- References: <20030701150147.11390.rcbilson@plg.uwaterloo.ca>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11390
------- Additional Comments From ehrhardt at mathematik dot uni-ulm dot de 2003-07-03 09:32 -------
This is a problem with the treatment of ``extern "C" int f();'' in
system headers. A further reduced example is this:
============== cut ===============
# 1 "p"
# 1 "x" 1 3
extern "C" int f();
# 5 "p" 2
extern "C" int f();
extern "C" int f();
============== cut ===============
The first declaration of f is in a system header where it is
interpreted as ``extern "C" int f (...);'' The second declaration is
interpreted as ``extern "C" int f (void);'' because it is outside of a
system header. These two declarations conflict but as the first one
is from a system header duplicate_decls merges them into one declaration
with a prototype of ``extern "C" int f(...);'' with the in_system_header_flag
cleared because the second declaration is not in a system header.
When we reach the third declaration we already have a declaration for
``extern "C" int f (...);'' but the new declaration is treated as
``extern "C" int f (void);'' because we are not in a system header.
As neither of these declarations has the in_system_header_flag set
they can't be merged.
Unfortunately it is not clear to me what the right fix is:
* We could keep the in_system_header_flag from olddecl in duplicate_decls.
The resulting prototype would be ``extern int f (...);''.
* duplicate_decls could choose ``extern int f (void);'' as the resulting
prototype if one of the declarations is not in a system header.
Currently a work around for the problem is to explicitly declare
f with the ``extern int f (...);'' prototype.
regards Christian