Bug 29411 - unique overload sets for extern "C" vs. C++ function pointers
Summary: unique overload sets for extern "C" vs. C++ function pointers
Status: RESOLVED DUPLICATE of bug 2316
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.2.0
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: ABI
Depends on:
Blocks:
 
Reported: 2006-10-10 10:07 UTC by Benjamin Kosnik
Modified: 2006-10-10 16:33 UTC (History)
8 users (show)

See Also:
Host: all
Target: all
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Benjamin Kosnik 2006-10-10 10:07:40 UTC
From comment #7 in 29095 we have:

The technical issue is that in the following code:

  extern "C" {
    typedef void (*p1)();
  }
  typedef void (*p2)();

p1 and p2 are distinct types, and, in fact, you can overload based on that. 
G++ doesn't implement that distinction; we don't keep track of language linkage
for types (just for functions) but we should, and, at some point, I'm sure
we'll implement that.  The reason this is in the standard is so that an
implementation can use different calling conventions for C and C++.  So, when
calling through a function pointer you have to know which kind of function
you're calling.  (And, yes, name-mangling is supposed to encode the linkage of
the function type, when mangling a pointer-to-function type.)

End of interesting comment. 

This was news to me, and a quick perusal of "5.1 External Names (a.k.a. Mangling)" in the IA64 C++ spec doesn't find any matches. However, I can see why this might be useful, and am curious as to the behavior of pre-3.0.x GNU compilers, as well as other ABI's (such as microsoft) or EDG in native mode.
Comment 1 Benjamin Kosnik 2006-10-10 10:09:01 UTC
This would be an enhancement to both g++ and the IA64 C++ ABI.
Comment 2 Andrew Pinski 2006-10-10 16:33:46 UTC
This is really a dup of bug 2316.  I forgot to mention that in PR 29095.
Oh and this is not an enhancement because you can have wrong code and also rejects valid testcases see the dup bug report about those cases.

*** This bug has been marked as a duplicate of 2316 ***