StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

POPossible ambiguity with extern "C", overloading, and function pointers
text
Body
copied!<p>With normal functions, one can write</p> <pre><code>extern "C" int Frotz(int); // in a header int Frotz(int x) { return x; } </code></pre> <p>With function pointers, however, this appears to have been implemented inconsistently between compilers.</p> <pre><code>extern "C" int Klutz(int (*)(int), int); int Klutz(int (*fptr)(int), int x) { return (*fptr)(x); } </code></pre> <p>In the declaration, the argument is also <code>extern "C"</code>. In the definition, most compilers appear to match these functions and make <code>Klutz</code> an <code>extern "C"</code> function. The Sun and Cray compilers, however, interpret these functions as being different, producing an overloaded <code>int Klutz(int (*fptr)(int), int x)</code>, which later generates a link-time error.</p> <p>Although Section 7.5.5 of C++98 and C++11 guarantees the interpretation of <code>Frotz</code>, I cannot tell if the standard is ambiguous about whether <code>extern "C"</code> matching should occur before or after checking for overloading.</p> <p>Should <code>Klutz</code> above generate a mangled (C++) symbol or an <code>extern "C"</code> symbol?</p> <h3>EDIT 1</h3> <p>I could use a typedef to disambiguate the function pointer to have C or C++ ABI, but I'm interested in whether the code here (a) defines <code>Klutz</code> to have C++ linkage, (b) defines it to have C linkage, or (c) is ambiguous according to the standard, so that compilers are free to choose how to interpret it.</p> <h3>EDIT 2</h3> <p>This appears to be a known issue, at least by those compilers with searchable bug trackers. In my tests, GCC, Clang, Intel, MSVC, IBM XL, PathScale, PGI, and Open64 all fail to distinguish function types that are identical except for language linkage, as explicitly required by the standard (see section 7.5.1, quoted in the accepted answer). Fixing this would break a lot of existing code and require an ABI change. I'm not aware of any compiler that actually uses a different calling convention for C versus C++ language linkage.</p> <ul> <li><p><a href="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316" rel="nofollow">GCC bug</a>: "Finding reasons to ask for the removal of this feature from the next standard is kind of relevant ;-)" ... "And we may even decide on an official WONTFIX."</p></li> <li><p><a href="http://llvm.org/bugs/show_bug.cgi?id=6277" rel="nofollow">Clang bug</a>: "I'm terrified of actually enforcing this rule, because doing it properly means making language linkage part of the canonical type, which is going to break a ton of code."</p></li> </ul>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload