Topic: Setting calling convention separately from rest
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 16 Oct 2013 11:22:34 -0700
Raw View
On quarta-feira, 16 de outubro de 2013 14:13:11, Jeremiah Willcock wrote:
> There does not appear to currently be a way to have a function with
> internal linkage but C calling convention: extern "C" uses external
> linkage, while "static" uses the C++ calling convention. The particular
> issue where this matters is in passing function pointers to C code. For
> example, there is no Standard-allowed way to pass an instance of a
> function template as a C function pointer without an extra layer of
> non-template wrapping. Would it make sense to have a construct
> that sets the calling convention but uses internal
> linkage, or a mechanism that only sets the calling convention without
> affecting linkage at all (to allow the kind of linkage used for template
> instances)? Because it would not affect name mangling, it could be
> applied to function templates as well, plus the names of these functions
> would not need to be unique across namespaces as with extern "C".
extern "C" {
static void f();
}
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Jeremiah Willcock <jewillco@crest.iu.edu>
Date: Wed, 16 Oct 2013 14:34:13 -0400 (EDT)
Raw View
On Wed, 16 Oct 2013, Thiago Macieira wrote:
> On quarta-feira, 16 de outubro de 2013 14:13:11, Jeremiah Willcock wrote:
>> There does not appear to currently be a way to have a function with
>> internal linkage but C calling convention: extern "C" uses external
>> linkage, while "static" uses the C++ calling convention. The particular
>> issue where this matters is in passing function pointers to C code. For
>> example, there is no Standard-allowed way to pass an instance of a
>> function template as a C function pointer without an extra layer of
>> non-template wrapping. Would it make sense to have a construct
>> that sets the calling convention but uses internal
>> linkage, or a mechanism that only sets the calling convention without
>> affecting linkage at all (to allow the kind of linkage used for template
>> instances)? Because it would not affect name mangling, it could be
>> applied to function templates as well, plus the names of these functions
>> would not need to be unique across namespaces as with extern "C".
>
> extern "C" {
> static void f();
> }
According to [dcl.link], this is supposed to work; however, it does not
work for a template (at least for a snapshot of GCC 4.9). I'm not sure
that is correct, though; [temp] paragraph 4 forbids a template with C
language linkage, but "static" should override the language linkage (even
in an extern "C" block) if I understand correctly.
-- Jeremiah Willcock
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 16 Oct 2013 12:01:12 -0700
Raw View
On quarta-feira, 16 de outubro de 2013 14:34:13, Jeremiah Willcock wrote:
> According to [dcl.link], this is supposed to work; however, it does not
> work for a template (at least for a snapshot of GCC 4.9). I'm not sure
> that is correct, though; [temp] paragraph 4 forbids a template with C
> language linkage, but "static" should override the language linkage (even
> in an extern "C" block) if I understand correctly.
The problem is not the static, in your case, it's the template.
Template functions always use C++ calling convention.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Jeremiah Willcock <jewillco@crest.iu.edu>
Date: Wed, 16 Oct 2013 15:05:39 -0400 (EDT)
Raw View
On Wed, 16 Oct 2013, Thiago Macieira wrote:
> On quarta-feira, 16 de outubro de 2013 14:34:13, Jeremiah Willcock wrote:
>> According to [dcl.link], this is supposed to work; however, it does not
>> work for a template (at least for a snapshot of GCC 4.9). I'm not sure
>> that is correct, though; [temp] paragraph 4 forbids a template with C
>> language linkage, but "static" should override the language linkage (even
>> in an extern "C" block) if I understand correctly.
>
> The problem is not the static, in your case, it's the template.
>
> Template functions always use C++ calling convention.
That is the part I suggest changing: have a way for templates to use the C
calling convention but not C language linkage.
-- Jeremiah Willcock
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 16 Oct 2013 12:57:17 -0700
Raw View
On quarta-feira, 16 de outubro de 2013 15:05:39, Jeremiah Willcock wrote:
> On Wed, 16 Oct 2013, Thiago Macieira wrote:
> > On quarta-feira, 16 de outubro de 2013 14:34:13, Jeremiah Willcock wrote:
> >> According to [dcl.link], this is supposed to work; however, it does not
> >> work for a template (at least for a snapshot of GCC 4.9). I'm not sure
> >> that is correct, though; [temp] paragraph 4 forbids a template with C
> >> language linkage, but "static" should override the language linkage (even
> >> in an extern "C" block) if I understand correctly.
> >
> > The problem is not the static, in your case, it's the template.
> >
> > Template functions always use C++ calling convention.
>
> That is the part I suggest changing: have a way for templates to use the C
> calling convention but not C language linkage.
That might not be possible.
Template functions must be decorated in order to even exist, regardless of
whether they have local scope or global scope. If a compiler ties decoration
to C++ calling convention, it might be difficult to disentangle.
That said, this is an artificial problem. All ABIs I know of use the C calling
convention for all non-member and static member functions. There's only one
compiler I know of (Sun CC) that even complains about it, but it still works.
If any compiler does not support that, you may want to contact the specific
compiler support team and request an extension to change the calling
convention instead. Note that calling conventions are technically outside the
scope of the C++ standard.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Wed, 16 Oct 2013 13:08:55 -0700
Raw View
--047d7bd6ae8c601f1204e8e145aa
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Oct 16, 2013 at 11:34 AM, Jeremiah Willcock
<jewillco@crest.iu.edu>wrote:
> On Wed, 16 Oct 2013, Thiago Macieira wrote:
>
> On quarta-feira, 16 de outubro de 2013 14:13:11, Jeremiah Willcock wrote:
>>
>>> There does not appear to currently be a way to have a function with
>>> internal linkage but C calling convention: extern "C" uses external
>>> linkage, while "static" uses the C++ calling convention. The particular
>>> issue where this matters is in passing function pointers to C code. For
>>> example, there is no Standard-allowed way to pass an instance of a
>>> function template as a C function pointer without an extra layer of
>>> non-template wrapping. Would it make sense to have a construct
>>> that sets the calling convention but uses internal
>>> linkage, or a mechanism that only sets the calling convention without
>>> affecting linkage at all (to allow the kind of linkage used for template
>>> instances)? Because it would not affect name mangling, it could be
>>> applied to function templates as well, plus the names of these functions
>>> would not need to be unique across namespaces as with extern "C".
>>>
>>
>> extern "C" {
>> static void f();
>> }
>>
>
> According to [dcl.link], this is supposed to work; however, it does not
> work for a template (at least for a snapshot of GCC 4.9). I'm not sure
> that is correct, though; [temp] paragraph 4 forbids a template with C
> language linkage, but "static" should override the language linkage (even
> in an extern "C" block) if I understand correctly.
You seem to be conflating two different kinds of language linkage. There is
language linkage on the *names* of external linkage functions and
variables, which (in practice) affects their name mangling. There is also
language linkage as a part of function *types*, which (in principle)
affects their calling convention. In practice, GCC (like most compilers)
does not implement the language linkage rules on types; see
http://gcc.gnu.org/PR2316
The above declaration of 'f' has no language linkage for its name (because
it doesn't have external linkage) but has C language linkage for its type.
It's not meaningful to give a function template specialization name a C
language linkage (because that would disable name mangling, which we need
for function template specializations). It would be meaningful to give such
a function template specialization's function type C language linkage, but
given that most current compilers (GCC included) don't treat language
linkage as being part of a function type, this would not provide any value
for users of those compilers.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7bd6ae8c601f1204e8e145aa
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wed, Oct 16, 2013 at 11:34 AM, Jeremiah Willcock <span =
dir=3D"ltr"><<a href=3D"mailto:jewillco@crest.iu.edu" target=3D"_blank">=
jewillco@crest.iu.edu</a>></span> wrote:<br><div class=3D"gmail_extra"><=
div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div class=3D"im">On Wed, 16 Oct 2013, Thiago Macieira wro=
te:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
On quarta-feira, 16 de outubro de 2013 14:13:11, Jeremiah Willcock wrote:<b=
r>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
There does not appear to currently be a way to have a function with<br>
internal linkage but C calling convention: extern "C" uses extern=
al<br>
linkage, while "static" uses the C++ calling convention. =A0The p=
articular<br>
issue where this matters is in passing function pointers to C code. For<br>
example, there is no Standard-allowed way to pass an instance of a<br>
function template as a C function pointer without an extra layer of<br>
non-template wrapping. =A0Would it make sense to have a construct<br>
that sets the calling convention but uses internal<br>
linkage, or a mechanism that only sets the calling convention without<br>
affecting linkage at all (to allow the kind of linkage used for template<br=
>
instances)? =A0Because it would not affect name mangling, it could be<br>
applied to function templates as well, plus the names of these functions<br=
>
would not need to be unique across namespaces as with extern "C".=
<br>
</blockquote>
<br>
extern "C" {<br>
=A0 =A0 =A0 =A0 static void f();<br>
}<br>
</blockquote>
<br></div>
According to [dcl.link], this is supposed to work; however, it does not wor=
k for a template (at least for a snapshot of GCC 4.9). =A0I'm not sure =
that is correct, though; [temp] paragraph 4 forbids a template with C langu=
age linkage, but "static" should override the language linkage (e=
ven in an extern "C" block) if I understand correctly.</blockquot=
e>
<div><br></div><div>You seem to be conflating two different kinds of langua=
ge linkage. There is language linkage on the *names* of external linkage fu=
nctions and variables, which (in practice) affects their name mangling. The=
re is also language linkage as a part of function *types*, which (in princi=
ple) affects their calling convention. In practice, GCC (like most compiler=
s) does not implement the language linkage rules on types; see=A0<a href=3D=
"http://gcc.gnu.org/PR2316">http://gcc.gnu.org/PR2316</a></div>
<div><br></div><div>The above declaration of 'f' has no language li=
nkage for its name (because it doesn't have external linkage) but has C=
language linkage for its type. It's not meaningful to give a function =
template specialization name a C language linkage (because that would disab=
le name mangling, which we need for function template specializations). It =
would be meaningful to give such a function template specialization's f=
unction type C language linkage, but given that most current compilers (GCC=
included) don't treat language linkage as being part of a function typ=
e, this would not provide any value for users of those compilers.</div>
</div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7bd6ae8c601f1204e8e145aa--
.
Author: Jeremiah Willcock <jewillco@crest.iu.edu>
Date: Wed, 16 Oct 2013 16:12:48 -0400 (EDT)
Raw View
On Wed, 16 Oct 2013, Richard Smith wrote:
> On Wed, Oct 16, 2013 at 11:34 AM, Jeremiah Willcock <jewillco@crest.iu.ed=
u> wrote:
> On Wed, 16 Oct 2013, Thiago Macieira wrote:
>
> On quarta-feira, 16 de outubro de 2013 14:13:11, Jeremiah Wil=
lcock wrote:
> There does not appear to currently be a way to have a f=
unction with
> internal linkage but C calling convention: extern "C" u=
ses external
> linkage, while "static" uses the C++ calling convention=
.. =A0The particular
> issue where this matters is in passing function pointer=
s to C code. For
> example, there is no Standard-allowed way to pass an in=
stance of a
> function template as a C function pointer without an ex=
tra layer of
> non-template wrapping. =A0Would it make sense to have a=
construct
> that sets the calling convention but uses internal
> linkage, or a mechanism that only sets the calling conv=
ention without
> affecting linkage at all (to allow the kind of linkage =
used for template
> instances)? =A0Because it would not affect name manglin=
g, it could be
> applied to function templates as well, plus the names o=
f these functions
> would not need to be unique across namespaces as with e=
xtern "C".
>=20
>
> extern "C" {
> =A0 =A0 =A0 =A0 static void f();
> }
>=20
>=20
> According to [dcl.link], this is supposed to work; however, it does not w=
ork for a template (at least for a snapshot of GCC 4.9). =A0I'm not sure
> that is correct, though; [temp] paragraph 4 forbids a template with C lan=
guage linkage, but "static" should override the language linkage (even in
> an extern "C" block) if I understand correctly.
>=20
>=20
> You seem to be conflating two different kinds of language linkage. There=
=20
> is language linkage on the *names* of external linkage functions and=20
> variables, which (in practice) affects their name mangling. There is=20
> also language linkage as a part of function *types*, which (in=20
> principle) affects their calling convention. In practice, GCC (like most=
=20
> compilers) does not implement the language linkage rules on types;=20
> see=A0http://gcc.gnu.org/PR2316
I agree, and understand it is portable in practice to assume C++ functions=
=20
can be used as C function pointers.
> The above declaration of 'f' has no language linkage for its name=20
> (because it doesn't have external linkage) but has C language linkage=20
> for its type. It's not meaningful to give a function template=20
> specialization name a C language linkage (because that would disable=20
> name mangling, which we need for function template specializations). It=
=20
> would be meaningful to give such a function template specialization's=20
> function type C language linkage, but given that most current compilers=
=20
> (GCC included) don't treat language linkage as being part of a function=
=20
> type, this would not provide any value for users of those compilers.
Yes -- I would like C++ language linkage (or internal, but not C language=
=20
linkage) for the function itself but C language linkage for its function=20
pointer type. It is more of a theoretical standards issue than a=20
practical problem, since I am relying on something nonstandard but common=
=20
in practice.
-- Jeremiah Willcock
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Wed, 16 Oct 2013 13:24:35 -0700
Raw View
--047d7bd6ae8c5c1a1f04e8e17d90
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Oct 16, 2013 at 1:12 PM, Jeremiah Willcock <jewillco@crest.iu.edu>wrote:
> On Wed, 16 Oct 2013, Richard Smith wrote:
>
> On Wed, Oct 16, 2013 at 11:34 AM, Jeremiah Willcock <
>> jewillco@crest.iu.edu> wrote:
>> On Wed, 16 Oct 2013, Thiago Macieira wrote:
>>
>> On quarta-feira, 16 de outubro de 2013 14:13:11, Jeremiah
>> Willcock wrote:
>> There does not appear to currently be a way to have a
>> function with
>> internal linkage but C calling convention: extern "C"
>> uses external
>> linkage, while "static" uses the C++ calling
>> convention. The particular
>> issue where this matters is in passing function
>> pointers to C code. For
>> example, there is no Standard-allowed way to pass an
>> instance of a
>> function template as a C function pointer without an
>> extra layer of
>> non-template wrapping. Would it make sense to have a
>> construct
>> that sets the calling convention but uses internal
>> linkage, or a mechanism that only sets the calling
>> convention without
>> affecting linkage at all (to allow the kind of linkage
>> used for template
>> instances)? Because it would not affect name mangling,
>> it could be
>> applied to function templates as well, plus the names
>> of these functions
>> would not need to be unique across namespaces as with
>> extern "C".
>>
>>
>> extern "C" {
>> static void f();
>> }
>>
>>
>> According to [dcl.link], this is supposed to work; however, it does not
>> work for a template (at least for a snapshot of GCC 4.9). I'm not sure
>> that is correct, though; [temp] paragraph 4 forbids a template with C
>> language linkage, but "static" should override the language linkage (even in
>> an extern "C" block) if I understand correctly.
>>
>>
>> You seem to be conflating two different kinds of language linkage. There
>> is language linkage on the *names* of external linkage functions and
>> variables, which (in practice) affects their name mangling. There is also
>> language linkage as a part of function *types*, which (in principle)
>> affects their calling convention. In practice, GCC (like most compilers)
>> does not implement the language linkage rules on types; see
>> http://gcc.gnu.org/PR2316
>>
>
> I agree, and understand it is portable in practice to assume C++ functions
> can be used as C function pointers.
>
>
> The above declaration of 'f' has no language linkage for its name
>> (because it doesn't have external linkage) but has C language linkage for
>> its type. It's not meaningful to give a function template specialization
>> name a C language linkage (because that would disable name mangling, which
>> we need for function template specializations). It would be meaningful to
>> give such a function template specialization's function type C language
>> linkage, but given that most current compilers (GCC included) don't treat
>> language linkage as being part of a function type, this would not provide
>> any value for users of those compilers.
>>
>
> Yes -- I would like C++ language linkage (or internal, but not C language
> linkage) for the function itself but C language linkage for its function
> pointer type. It is more of a theoretical standards issue than a practical
> problem, since I am relying on something nonstandard but common in practice.
We discussed one possible way of achieving this in CWG: we could allow
alias templates to be declared with C language linkage:
extern "C" template<typename T> using MyFnType = void (T);
template<typename T> MyFnType<T> f; // ok, C++ language linkage for name, C
language linkage for type
template<typename T> void f(T t) { // ok, inherits language linkage for type
// ...
}
.... but we concluded that this is in EWG's area, and there are probably
better ways to get the same effect (for instance, allow templates inside C
language linkage blocks in general, but only apply the linkage to the type
and not to the name, much as we -- in effect -- do for extern "C"
overloaded operators).
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7bd6ae8c5c1a1f04e8e17d90
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wed, Oct 16, 2013 at 1:12 PM, Jeremiah Willcock <span d=
ir=3D"ltr"><<a href=3D"mailto:jewillco@crest.iu.edu" target=3D"_blank">j=
ewillco@crest.iu.edu</a>></span> wrote:<br><div class=3D"gmail_extra"><d=
iv class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Wed, 16 Oct 2013, Richa=
rd Smith wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On Wed, Oct 16, 2013 at 11:34 AM, Jeremiah Willcock <<a href=3D"mailto:j=
ewillco@crest.iu.edu" target=3D"_blank">jewillco@crest.iu.edu</a>> wrote=
:<br>
=A0 =A0 =A0 On Wed, 16 Oct 2013, Thiago Macieira wrote:<br>
<br>
=A0 =A0 =A0 =A0 =A0 =A0 On quarta-feira, 16 de outubro de 2013 14:13:11, Je=
remiah Willcock wrote:<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 There does not appear to currently be a=
way to have a function with<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 internal linkage but C calling conventi=
on: extern "C" uses external<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 linkage, while "static" uses =
the C++ calling convention. =A0The particular<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 issue where this matters is in passing =
function pointers to C code. For<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 example, there is no Standard-allowed w=
ay to pass an instance of a<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 function template as a C function point=
er without an extra layer of<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 non-template wrapping. =A0Would it make=
sense to have a construct<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 that sets the calling convention but us=
es internal<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 linkage, or a mechanism that only sets =
the calling convention without<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 affecting linkage at all (to allow the =
kind of linkage used for template<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 instances)? =A0Because it would not aff=
ect name mangling, it could be<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 applied to function templates as well, =
plus the names of these functions<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 would not need to be unique across name=
spaces as with extern "C".<br>
<br>
<br>
=A0 =A0 =A0 =A0 =A0 =A0 extern "C" {<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 static void f();<br>
=A0 =A0 =A0 =A0 =A0 =A0 }<br>
<br>
<br>
According to [dcl.link], this is supposed to work; however, it does not wor=
k for a template (at least for a snapshot of GCC 4.9). =A0I'm not sure<=
br>
that is correct, though; [temp] paragraph 4 forbids a template with C langu=
age linkage, but "static" should override the language linkage (e=
ven in<br>
an extern "C" block) if I understand correctly.<br>
<br>
<br>
You seem to be conflating two different kinds of language linkage. There is=
language linkage on the *names* of external linkage functions and variable=
s, which (in practice) affects their name mangling. There is also language =
linkage as a part of function *types*, which (in principle) affects their c=
alling convention. In practice, GCC (like most compilers) does not implemen=
t the language linkage rules on types; see=A0<a href=3D"http://gcc.gnu.org/=
PR2316" target=3D"_blank">http://gcc.gnu.org/PR2316</a><br>
</blockquote>
<br></div>
I agree, and understand it is portable in practice to assume C++ functions =
can be used as C function pointers.<div class=3D"im"><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
The above declaration of 'f' has no language linkage for its name (=
because it doesn't have external linkage) but has C language linkage fo=
r its type. It's not meaningful to give a function template specializat=
ion name a C language linkage (because that would disable name mangling, wh=
ich we need for function template specializations). It would be meaningful =
to give such a function template specialization's function type C langu=
age linkage, but given that most current compilers (GCC included) don't=
treat language linkage as being part of a function type, this would not pr=
ovide any value for users of those compilers.<br>
</blockquote>
<br></div>
Yes -- I would like C++ language linkage (or internal, but not C language l=
inkage) for the function itself but C language linkage for its function poi=
nter type. =A0It is more of a theoretical standards issue than a practical =
problem, since I am relying on something nonstandard but common in practice=
..</blockquote>
<div><br></div><div>We discussed one possible way of achieving this in CWG:=
we could allow alias templates to be declared with C language linkage:</di=
v><div><br></div><div>extern "C" template<typename T> using=
MyFnType =3D void (T);</div>
<div>template<typename T> MyFnType<T> f; // ok, C++ language li=
nkage for name, C language linkage for type</div><div>template<typename =
T> void f(T t) { // ok, inherits language linkage for type</div><div>
=A0 // ...</div><div>}</div><div><br></div><div>... but we concluded that t=
his is in EWG's area, and there are probably better ways to get the sam=
e effect (for instance, allow templates inside C language linkage blocks in=
general, but only apply the linkage to the type and not to the name, much =
as we -- in effect -- do for extern "C" overloaded operators).</d=
iv>
</div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7bd6ae8c5c1a1f04e8e17d90--
.
Author: Tom Honermann <thonermann@coverity.com>
Date: Thu, 17 Oct 2013 21:23:05 -0700 (PDT)
Raw View
------=_Part_1333_9649267.1382070185404
Content-Type: text/plain; charset=ISO-8859-1
On Wednesday, October 16, 2013 3:57:17 PM UTC-4, Thiago Macieira wrote:
> That said, this is an artificial problem. All ABIs I know of use the C
> calling
> convention for all non-member and static member functions. There's only
> one
> compiler I know of (Sun CC) that even complains about it, but it still
> works.
>
IBM's XL C/C++ compiler for z/OS has different calling conventions for C vs
C++
when using the traditional ABI. A new linkage kind was introduced a number
of
years ago (XPLINK) that provides a uniform calling convention, but
developers
have to opt in to using it.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1333_9649267.1382070185404
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, October 16, 2013 3:57:17 PM UTC-4, Thiago Ma=
cieira wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">That said, th=
is is an artificial problem. All ABIs I know of use the C calling=20
<br>convention for all non-member and static member functions. There's only=
one=20
<br>compiler I know of (Sun CC) that even complains about it, but it still =
works.
<br></blockquote><div><br>IBM's XL C/C++ compiler for z/OS has different ca=
lling conventions for C vs C++<br>when using the traditional ABI. A n=
ew linkage kind was introduced a number of<br>years ago (XPLINK) that provi=
des a uniform calling convention, but developers<br>have to opt in to using=
it.<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1333_9649267.1382070185404--
.