Boost logo

Boost :

Subject: Re: [boost] [winapi] Problem with the latest clang on Windows
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-06-01 18:57:50


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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk