* [Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage
[not found] <bug-70476-4@http.gcc.gnu.org/bugzilla/>
@ 2021-08-27 0:05 ` pinskia at gcc dot gnu.org
2021-08-27 9:17 ` redi at gcc dot gnu.org
` (12 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-08-27 0:05 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage
[not found] <bug-70476-4@http.gcc.gnu.org/bugzilla/>
2021-08-27 0:05 ` [Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage pinskia at gcc dot gnu.org
@ 2021-08-27 9:17 ` redi at gcc dot gnu.org
2021-08-27 9:18 ` redi at gcc dot gnu.org
` (11 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: redi at gcc dot gnu.org @ 2021-08-27 9:17 UTC (permalink / raw)
To: gcc-bugs
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."
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage
[not found] <bug-70476-4@http.gcc.gnu.org/bugzilla/>
2021-08-27 0:05 ` [Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage pinskia at gcc dot gnu.org
2021-08-27 9:17 ` redi at gcc dot gnu.org
@ 2021-08-27 9:18 ` redi at gcc dot gnu.org
2021-08-27 9:27 ` redi at gcc dot gnu.org
` (10 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: redi at gcc dot gnu.org @ 2021-08-27 9:18 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage
[not found] <bug-70476-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2021-08-27 9:18 ` redi at gcc dot gnu.org
@ 2021-08-27 9:27 ` redi at gcc dot gnu.org
2021-08-27 9:34 ` redi at gcc dot gnu.org
` (9 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: redi at gcc dot gnu.org @ 2021-08-27 9:27 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage
[not found] <bug-70476-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2021-08-27 9:27 ` redi at gcc dot gnu.org
@ 2021-08-27 9:34 ` redi at gcc dot gnu.org
2023-03-11 23:32 ` mail at maciej dot szmigiero.name
` (8 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: redi at gcc dot gnu.org @ 2021-08-27 9:34 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage
[not found] <bug-70476-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2021-08-27 9:34 ` redi at gcc dot gnu.org
@ 2023-03-11 23:32 ` mail at maciej dot szmigiero.name
2023-03-11 23:43 ` pinskia at gcc dot gnu.org
` (7 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: mail at maciej dot szmigiero.name @ 2023-03-11 23:32 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage
[not found] <bug-70476-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2023-03-11 23:32 ` mail at maciej dot szmigiero.name
@ 2023-03-11 23:43 ` pinskia at gcc dot gnu.org
2023-03-11 23:53 ` pinskia at gcc dot gnu.org
` (6 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-03-11 23:43 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage
[not found] <bug-70476-4@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2023-03-11 23:43 ` pinskia at gcc dot gnu.org
@ 2023-03-11 23:53 ` pinskia at gcc dot gnu.org
2023-03-12 0:48 ` mail at maciej dot szmigiero.name
` (5 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-03-11 23:53 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage
[not found] <bug-70476-4@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2023-03-11 23:53 ` pinskia at gcc dot gnu.org
@ 2023-03-12 0:48 ` mail at maciej dot szmigiero.name
2023-03-13 4:58 ` de34 at live dot cn
` (4 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: mail at maciej dot szmigiero.name @ 2023-03-12 0:48 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage
[not found] <bug-70476-4@http.gcc.gnu.org/bugzilla/>
` (8 preceding siblings ...)
2023-03-12 0:48 ` mail at maciej dot szmigiero.name
@ 2023-03-13 4:58 ` de34 at live dot cn
2023-03-13 5:03 ` de34 at live dot cn
` (3 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: de34 at live dot cn @ 2023-03-13 4:58 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage
[not found] <bug-70476-4@http.gcc.gnu.org/bugzilla/>
` (9 preceding siblings ...)
2023-03-13 4:58 ` de34 at live dot cn
@ 2023-03-13 5:03 ` de34 at live dot cn
2023-03-13 11:23 ` mail at maciej dot szmigiero.name
` (2 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: de34 at live dot cn @ 2023-03-13 5:03 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage
[not found] <bug-70476-4@http.gcc.gnu.org/bugzilla/>
` (10 preceding siblings ...)
2023-03-13 5:03 ` de34 at live dot cn
@ 2023-03-13 11:23 ` mail at maciej dot szmigiero.name
2023-03-13 12:23 ` de34 at live dot cn
2023-03-16 16:48 ` mail at maciej dot szmigiero.name
13 siblings, 0 replies; 14+ messages in thread
From: mail at maciej dot szmigiero.name @ 2023-03-13 11:23 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage
[not found] <bug-70476-4@http.gcc.gnu.org/bugzilla/>
` (11 preceding siblings ...)
2023-03-13 11:23 ` mail at maciej dot szmigiero.name
@ 2023-03-13 12:23 ` de34 at live dot cn
2023-03-16 16:48 ` mail at maciej dot szmigiero.name
13 siblings, 0 replies; 14+ messages in thread
From: de34 at live dot cn @ 2023-03-13 12:23 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage
[not found] <bug-70476-4@http.gcc.gnu.org/bugzilla/>
` (12 preceding siblings ...)
2023-03-13 12:23 ` de34 at live dot cn
@ 2023-03-16 16:48 ` mail at maciej dot szmigiero.name
13 siblings, 0 replies; 14+ messages in thread
From: mail at maciej dot szmigiero.name @ 2023-03-16 16:48 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread