[Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage

[Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70476

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
GCC, clang, ICC, and MSVC all agree they have external linkage.

[Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70476

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
[dcl.link] p8:

"A declaration directly contained in a linkage-specification is treated as if
it contains the extern specifier (9.2.2) for the purpose of determining the
linkage of the declared name and whether it is a definition. Such a declaration
shall not specify a storage class."

[Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70476

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Since language linkage of an entity without linkage makes no sense, it wouldn't
make sense to even allow specifying language linkage in an unnamed namespace if
it did nothing.

[Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70476

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Actually I suppose that's not true, since in theory C language linkage gives
the function a different type, orthogonal from internal/external/no linkage,
but nobody implements that.

[Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70476

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |NEW
     Ever confirmed|0                           |1
         Resolution|INVALID                     |---
   Last reconfirmed|                            |2021-08-27

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
This is not very helpful:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#2230

A discussion in 2017 concluded that Stephan is correct, but that never made it
to the issues list. So confirming as a bug.

[Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage

[mail at maciej dot szmigiero.name]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70476

Maciej S. Szmigiero <mail at maciej dot szmigiero.name> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mail at maciej dot szmigiero.name

--- Comment #8 from Maciej S. Szmigiero <mail at maciej dot szmigiero.name> ---
Having functions with "C" language linkage (calling convention, etc) but
internal linkage is useful for writing callbacks provided to C functions.

It's not an significant issue, however, as one can get the same effect by
declaring the callback function "static" inside an "extern C" block.

[Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70476

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Does these two functions the same name then?
```
namespace a {
   extern "C" void f(void);
}

namespace {
  extern "C" void f(void) {}
}

void g(void)
{
  f();
  a::f();
}

```
It seems counter intuitive that a::f and the ::f map to different functions.

[Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70476

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |assemble-failure

--- Comment #10 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I see no implementation (MSVC, GCC, clang) implements this at all.
Here is an example where GCC produces an assembly failure:
```
namespace a {
   extern "C" void f(void){}
}

namespace {
  extern "C" void f(void) {}
}

int main(void)
{
  f();
  a::f();
}
```

It might be handle to implement this even correctly too.

[Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage

[mail at maciej dot szmigiero.name]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70476

--- Comment #11 from Maciej S. Szmigiero <mail at maciej dot szmigiero.name> ---
(In reply to Andrew Pinski from comment #9)
> Does these two functions the same name then?
> ```
> namespace a {
>    extern "C" void f(void);
> }
> 
> namespace {
>   extern "C" void f(void) {}
> }
> 
> void g(void)
> {
>   f();
>   a::f();
> }
> 
> ```
> It seems counter intuitive that a::f and the ::f map to different functions.

According to [dcl.link] "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", so it would
seem that both refer to the same function indeed.

> Here is an example where GCC produces an assembly failure:
>
> namespace a {
>    extern "C" void f(void){}
> }
> 
> namespace {
>   extern "C" void f(void) {}
> }

If they are the same function then this shouldn't work (it would be a
re-definition).

[Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage

[de34 at live dot cn]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70476

Jiang An <de34 at live dot cn> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |de34 at live dot cn

--- Comment #12 from Jiang An <de34 at live dot cn> ---
It seems that the current specification is still broken for extern "C"
functions with internal linkage.(In reply to Maciej S. Szmigiero from comment
#8)
> Having functions with "C" language linkage (calling convention, etc) but
> internal linkage is useful for writing callbacks provided to C functions.
> 
> It's not an significant issue, however, as one can get the same effect by
> declaring the callback function "static" inside an "extern C" block.

This is not so useful in practice because most compilers don't make extern "C"
and extern "C++" differentiate function types (implying calling conventions
etc.).

There's a long battle story, and the divergence between the standard and
implementations is not resolved yet. See
https://cplusplus.github.io/CWG/issues/1555.html
https://lists.isocpp.org/sg12/2020/04/0900.php

[Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage

[de34 at live dot cn]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70476

--- Comment #13 from Jiang An <de34 at live dot cn> ---
(In reply to Maciej S. Szmigiero from comment #11)
> (In reply to Andrew Pinski from comment #9)
> > Does these two functions the same name then?
> > ```
> > namespace a {
> >    extern "C" void f(void);
> > }
> > 
> > namespace {
> >   extern "C" void f(void) {}
> > }
> > 
> > void g(void)
> > {
> >   f();
> >   a::f();
> > }
> > 
> > ```
> > It seems counter intuitive that a::f and the ::f map to different functions.
> 
> According to [dcl.link] "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", so it
> would seem that both refer to the same function indeed.
> 
> > Here is an example where GCC produces an assembly failure:
> >
> > namespace a {
> >    extern "C" void f(void){}
> > }
> > 
> > namespace {
> >   extern "C" void f(void) {}
> > }
> 
> If they are the same function then this shouldn't work (it would be a
> re-definition).

Oh, I think they shouldn't be the same function.

[dcl.link]/1 says:
> All functions and variables whose names have external linkage and all
> function types have a language linkage.

which implies that a function with internal linkage doesn't have a language
linkage, and thus [dcl.link]/7 doesn't apply to it.

[Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage

[mail at maciej dot szmigiero.name]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70476

--- Comment #14 from Maciej S. Szmigiero <mail at maciej dot szmigiero.name> ---
> This is not so useful in practice because most compilers don't make extern "C" and extern "C++" differentiate function types (implying calling conventions etc.).

The standard allows different calling conventions for "C" and "C++" language
linkage and that's what matters when writing standard-compliant code - one
shouldn't write to a particular implementation (or implementations).

> > All functions and variables whose names have external linkage and all
> > function types have a language linkage.
> 
> which implies that a function with internal linkage doesn't have a language > linkage, and thus [dcl.link]/7 doesn't apply to it.

Nothing in the above quote says that *only* these specified have a language
linkage, just that these explicitly enumerated sure do.

[Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage

[de34 at live dot cn]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70476

--- Comment #15 from Jiang An <de34 at live dot cn> ---
(In reply to Maciej S. Szmigiero from comment #14)
> > This is not so useful in practice because most compilers don't make extern "C" and extern "C++" differentiate function types (implying calling conventions etc.).
> 
> The standard allows different calling conventions for "C" and "C++" language
> linkage and that's what matters when writing standard-compliant code - one
> shouldn't write to a particular implementation (or implementations).
> 

The problem in pratice is that most implementations are not standard-compliant
here. If you rely on the standard guarantee that extern "C" and extern "C++"
make function types different, you probably get compilation errors.

> > > All functions and variables whose names have external linkage and all
> > > function types have a language linkage.
> > 
> > which implies that a function with internal linkage doesn't have a language > linkage, and thus [dcl.link]/7 doesn't apply to it.
> 
> Nothing in the above quote says that *only* these specified have a language
> linkage, just that these explicitly enumerated sure do.


I think the italic style is "the thing", which should mean that the term
"language linkage" is introduced and restricted here.

[Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage

[mail at maciej dot szmigiero.name]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70476

--- Comment #16 from Maciej S. Szmigiero <mail at maciej dot szmigiero.name> ---
> If you rely on the standard guarantee that extern "C" and extern "C++" make function types different, you probably get compilation errors.

It's the other way around - functions in standard-compliant code should have
proper language linkage markings (including implicit markings).

They are needed in case some compiler or platform decides that, for example,
"C" and "C++" language linkages need to have different calling conventions.
Which is something that the standard allows.

However, this bug is about having internal linkage for all anonymous namespace
functions (including the ones declared with "C" language linkage) - whether "C"
and "C++" language linkages should be allowed to have different calling
conventions is a different matter.