On 6/1/2015 6:57 PM, Andrey Semashev wrote:
On Monday 01 June 2015 17:56:59 Edward Diener wrote:
On 6/1/2015 3:12 PM, Andrey Semashev wrote:
On Monday 01 June 2015 11:23:36 Edward Diener wrote:
What does the C++ standard say about the extern "C" declarations duplicating the same name as regular declarations but different types. Is it an ODR violation ? Maybe that is what the clang problem is about although gcc does not feel it is a problem seeing the exact same preprocessed output.
I could only find 7.5/6: ...Two declarations for a function with C language linkage with the same function name (ignoring the namespace names that qualify it) that appear in different namespace scopes refer to the same function....
It doesn't say anything about argument types. ODR also doesn't apply here since we're talking about the function declaration, not its definition.
OK, so just declaring a function with the same name but different signature doesn't mean a compiler error. But when we invoke the function with a signature that matches one of the declarations does the C++ standard say it is an error because another declaration with the same name but a different signature exists ? Evidently clang thinks it is an error but gcc does not.
I didn't find any specifics on this (but I could be missing something). The extern "C" linkage affects overload resolution (13.3.2/3), so that if there are two viable extern "C" function declarations that are in different namespaces are visible at the call site, the two declarations do not conflict as they are considered to declare the one and only extern "C" function. But then again, the example does not consider the case when the two declarations differ in arguments. The standard also mentions that language-specific linkage may have other effects, such as special name mangling or calling conventions (7.5/1), but naturally, it doesn't go into specifics of these effects.
Since other than the above there are no special treatment of extern "C" function calls from the language perspective, I would assume that as long as the call in unambiguous by the C++ overload resolution rules, the language should allow it.
If clang folks say this should not compile then perhaps they could point to the relevant part of the standard.
The reply from clang was quick on the bug report: "The problem is that the two function declarations have different parameter types. The windows.h version takes ::_FILETIME*, whereas the boost version takes boost::detail::winapi::_FILETIME*. Because they're 'extern "C"' functions, they are redeclarations of the same function, and are ill-formed because they have different types." I have asked for the appropriate place in the C++ standard which justifies the error.