Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #81161 > unrolled thread

Can extern "C" functions throw exceptions

Back to article view | Back to comp.lang.c++

Contents

  Can extern "C" functions throw exceptions Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-11 12:35 +0200
    Re: Can extern "C" functions throw exceptions Bo Persson <bo@bo-persson.se> - 2021-09-11 13:49 +0200
      Re: Can extern "C" functions throw exceptions "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-09-11 13:57 +0200
      Re: Can extern "C" functions throw exceptions Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-11 15:19 +0300
      Re: Can extern "C" functions throw exceptions Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-11 15:32 +0200
      Re: Can extern "C" functions throw exceptions HorseyWorsey@the_stables.com - 2021-09-11 15:54 +0000
    Re: Can extern "C" functions throw exceptions "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-09-11 13:55 +0200
      Re: Can extern "C" functions throw exceptions Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-11 15:34 +0200
        Re: Can extern "C" functions throw exceptions Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-11 15:58 +0200
        Re: Can extern "C" functions throw exceptions "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-09-11 17:00 +0200
          Re: Can extern "C" functions throw exceptions "daniel...@gmail.com" <danielaparker@gmail.com> - 2021-10-06 13:36 -0700
            Re: Can extern "C" functions throw exceptions Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-06 20:42 +0000
              Re: Can extern "C" functions throw exceptions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-06 16:12 -0700
                Re: Can extern "C" functions throw exceptions Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-06 23:22 +0000
                  Re: Can extern "C" functions throw exceptions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-06 17:03 -0700
      Re: Can extern "C" functions throw exceptions HorseyWorsey@the_stables.com - 2021-09-11 15:56 +0000
      Re: Can extern "C" functions throw exceptions David Brown <david.brown@hesbynett.no> - 2021-09-11 20:10 +0200
        Re: Can extern "C" functions throw exceptions Juha Nieminen <nospam@thanks.invalid> - 2021-09-12 09:20 +0000
          Re: Can extern "C" functions throw exceptions Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-12 12:34 +0300
          Re: Can extern "C" functions throw exceptions David Brown <david.brown@hesbynett.no> - 2021-09-12 12:24 +0200
            Re: Can extern "C" functions throw exceptions Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-12 12:29 +0200
          Re: Can extern "C" functions throw exceptions Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2021-09-12 14:44 +0100
            Re: Can extern "C" functions throw exceptions James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-12 23:13 -0400
              Re: Can extern "C" functions throw exceptions David Brown <david.brown@hesbynett.no> - 2021-09-13 09:30 +0200
              Re: Can extern "C" functions throw exceptions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-06 13:12 -0700
                Re: Can extern "C" functions throw exceptions "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-10-07 07:09 -0700
                  Re: Can extern "C" functions throw exceptions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-14 15:21 -0800
                    Re: Can extern "C" functions throw exceptions Richard Damon <Richard@Damon-Family.org> - 2021-12-14 21:17 -0500
                      Re: Can extern "C" functions throw exceptions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-16 04:21 -0800
                    Re: Can extern "C" functions throw exceptions "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-12-14 19:06 -0800
                      Re: Can extern "C" functions throw exceptions Ian Collins <ian-news@hotmail.com> - 2021-12-16 13:14 +1300
                        Re: Can extern "C" functions throw exceptions "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-12-15 18:05 -0800
                        Re: Can extern "C" functions throw exceptions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-16 04:37 -0800
                          Re: Can extern "C" functions throw exceptions Ian Collins <ian-news@hotmail.com> - 2021-12-17 09:39 +1300
                            Re: Can extern "C" functions throw exceptions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-16 19:24 -0800
                      Re: Can extern "C" functions throw exceptions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-16 04:29 -0800
            Re: Can extern "C" functions throw exceptions Juha Nieminen <nospam@thanks.invalid> - 2021-09-13 05:34 +0000
              Re: Can extern "C" functions throw exceptions Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-13 09:55 +0300
    Re: Can extern "C" functions throw exceptions Paavo Helde <myfirstname@osa.pri.ee> - 2021-09-11 15:12 +0300
    Re: Can extern "C" functions throw exceptions red floyd <no.spam.here@its.invalid> - 2021-09-13 13:21 -0700

Page 2 of 2 — ← Prev page 1 [2]

#81207

Am 12.09.2021 um 12:24 schrieb David Brown:

> Although in theory a compiler can support different ABI's or calling
> conventions for C and C++ functions, in practice making a function
> extern "C" simply disables all name mangling for the function. That
> in turn means you can't overload it, or have it in a namespace.

You can actually define it in a namespace, but it won't belong to it.

[toc] | [prev] | [next] | [standalone]

#81215

On Sun, 12 Sep 2021 09:20:23 -0000 (UTC)
Juha Nieminen <nospam@thanks.invalid> wrote:
> David Brown <david.brown@hesbynett.no> wrote:
> > extern "C" marks the function as having C naming conventions and C
> > calling conventions
> 
> Indeed, extern "C" doesn't mean that the code being called using
> those functions has actually been compiled as C. It merely changes
> the naming of the functions in the object files to be compatible
> with how functions are named in C.

For functions, it does more than affecting naming.  The language linkage
of a function determines two things: the function's name (name mangling)
and the function's type (calling convention).  For example a function
pointer has language linkage for its function type even though name
mangling is irrelevant to it (save as mentioned further below with
respect to variable names).  gcc allows you to pass a function pointer
with C++ language linkage to a C function expecting a C function
pointer, but strictly speaking it is undefined behaviour.  I believe
some of the intel compilers did indeed have a different calling
convention as respects use of registers as between C and C++ functions.

> But that makes me wonder: If an extern "C" declared function has
> C++ types as parameters (or return value type), how are those
> encoded in the name? Or are they at all? Can you overload extern "C"
> functions?

In C++ variables also have a language linkage ("All function types,
function names with external linkage, and variable names with external
linkage have a language linkage").  But I know of no compiler which
actually does distinguish between the language linkage of C and C++
variable names.  Function pointers which are lvalues have a language
linkage with respect to the variable name (if any) of the pointer and as
regards the type (calling convention) of the pointed-to function.  As
mentioned, the language linkage of the variable name is in practice
immaterial.

Functions with C language linkage cannot be overridden because name
mangling is suppressed by C name mangling (the prepending of an
underscore).  As regards argument types, of necessity the only function
with C language linkage which could take, say, a std::string argument
is a C++ function declared to have C language linkage.

[toc] | [prev] | [next] | [standalone]

#81233

On 9/12/21 9:44 AM, Chris Vine wrote:
> On Sun, 12 Sep 2021 09:20:23 -0000 (UTC)
> Juha Nieminen <nospam@thanks.invalid> wrote:
...
>> Indeed, extern "C" doesn't mean that the code being called using
>> those functions has actually been compiled as C. It merely changes
>> the naming of the functions in the object files to be compatible
>> with how functions are named in C.
> 
> For functions, it does more than affecting naming.  The language linkage
> of a function determines two things: the function's name (name mangling)
> and the function's type (calling convention).

Furthermore, and not widely appreciated, those two aspects are separable
by using a typedef for a function's type. The language linkage of the
typedef determines the calling convention, while the language linkage of
the function itself determines the name mangling.

[toc] | [prev] | [next] | [standalone]

#81241

On 13/09/2021 05:13, James Kuyper wrote:
> On 9/12/21 9:44 AM, Chris Vine wrote:
>> On Sun, 12 Sep 2021 09:20:23 -0000 (UTC)
>> Juha Nieminen <nospam@thanks.invalid> wrote:
> ...
>>> Indeed, extern "C" doesn't mean that the code being called using
>>> those functions has actually been compiled as C. It merely changes
>>> the naming of the functions in the object files to be compatible
>>> with how functions are named in C.
>>
>> For functions, it does more than affecting naming.  The language linkage
>> of a function determines two things: the function's name (name mangling)
>> and the function's type (calling convention).
> 
> Furthermore, and not widely appreciated, those two aspects are separable
> by using a typedef for a function's type. The language linkage of the
> typedef determines the calling convention, while the language linkage of
> the function itself determines the name mangling.
> 

That is not something I knew.

It does not affect my own coding, as I know the ABI's are the same for C
and C++ and everything is handled by the same compiler.  But it might be
relevant in odd cases.

One thing that might be relevant in the future is some of the ideas
being considered for changing exceptions into a simpler and more
deterministic system, with far lower overheads, clearer code and better
checking by making them more static and less run-time.  Some of the
papers around this have suggested using additional registers or
processor flags as cheap ways to return exception information to the
caller - and that might mean a change to the C++ ABI compared to the C
ABI on the same platform, even for otherwise simple function parameters.

[toc] | [prev] | [next] | [standalone]

#81882

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> On 9/12/21 9:44 AM, Chris Vine wrote:
>
>> On Sun, 12 Sep 2021 09:20:23 -0000 (UTC)
>> Juha Nieminen <nospam@thanks.invalid> wrote:
>
> ...
>
>>> Indeed, extern "C" doesn't mean that the code being called using
>>> those functions has actually been compiled as C. It merely changes
>>> the naming of the functions in the object files to be compatible
>>> with how functions are named in C.
>>
>> For functions, it does more than affecting naming.  The language
>> linkage of a function determines two things:  the function's name
>> (name mangling) and the function's type (calling convention).
>
> Furthermore, and not widely appreciated, those two aspects are
> separable by using a typedef for a function's type.  The language
> linkage of the typedef determines the calling convention, while the
> language linkage of the function itself determines the name
> mangling.

Can you illustrate how that would be done?  Since the language
linkage of a function is part of its type, it sounds like trying
to do such a thing would inevitably lead to undefined behavior.

[toc] | [prev] | [next] | [standalone]

#81913

On Wednesday, October 6, 2021 at 4:12:52 PM UTC-4, Tim Rentsch wrote:
> James Kuyper <james...@alumni.caltech.edu> writes: 
> 
> > On 9/12/21 9:44 AM, Chris Vine wrote: 
...
> >> For functions, it does more than affecting naming. The language 
> >> linkage of a function determines two things: the function's name 
> >> (name mangling) and the function's type (calling convention). 
> > 
> > Furthermore, and not widely appreciated, those two aspects are 
> > separable by using a typedef for a function's type. The language 
> > linkage of the typedef determines the calling convention, while the 
> > language linkage of the function itself determines the name 
> > mangling.
> Can you illustrate how that would be done? Since the language 
> linkage of a function is part of its type, it sounds like trying 
> to do such a thing would inevitably lead to undefined behavior.

The language linkage of a function's type is indeed part of that type. The
language linkage of a function's name is not. The standard's description of
language linkage in 9.11p1 starts with the sentence "All function types,
function names with external linkage, and variable names with external
linkage have a language linkage.", clearly making the point that the
language linkage of a function's type is a distinct thing from the language
linkage of a function's name.  The standard could have inextricably linked
them together - but it does not. In fact, 9.11p5 includes an example
demonstrating how they can be separated:

    extern "C" typedef void FUNC();
    FUNC f2;  // the name f2 has C ++ language linkage and the
                     // function’s type has C language linkage

Now, the standard can and does contain example code that violates a C++
rule, as a way of explaining what that rule means. However, when it does so,
it almost always includes a comment next to the offending line pointing out
that it violates a rule. There's no such comment in this example. In fact, the
only comments explicitly describe the well-defined meaning of that code.

All quotes are from n4860.pdf, the latest draft version of the C++ language
that I have access to. However, this is not a new feature of the language; it
has been part of standard C++ for as long as C++ has been standardized.
I'm not sure about pre-standard C++ - my copy of Stroustrup's book went
missing many years ago.

The C++ language linkage of f2's name means that it can be referred to by
name in C++ code, but not in C code. The C language linkage of f2's type
means that f2 can called from C as well as from C++. However, since the
function's name can't be referred to by C code, it must be called using a
pointer, and that pointer's value can only come from C++ code. It could be
passed to the C part of a program as a function parameter, or returned as
the value of a function call, or placed in a function pointer object shared
between the C and C++ parts of a program.

I don't see any reasonable use for the opposite: a function whose name has
C language linkage and whose type has C++ language linkage. C has no way
of correctly declaring the type of the function associated with that name,
and the function's name cannot be declared without specifying it's type.
Such a function would be callable by name from C++ but I don't see any
particular advantage of that.

I don't think that the ability to separate the language linkage of a function's
type from the language linkage of the function's name was a strongly desired
feature in itself. I suspect that it is simply a side-effect that arose naturally
from the fact that those are two different aspects of language linkage,
combined with the way typedefs work.

[toc] | [prev] | [next] | [standalone]

#82643

"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:

> On Wednesday, October 6, 2021 at 4:12:52 PM UTC-4, Tim Rentsch wrote:
>
>> James Kuyper <james...@alumni.caltech.edu> writes:
>>
>>> On 9/12/21 9:44 AM, Chris Vine wrote:
>
> ...
>
>>>> For functions, it does more than affecting naming.  The language
>>>> linkage of a function determines two things:  the function's name
>>>> (name mangling) and the function's type (calling convention).
>>>
>>> Furthermore, and not widely appreciated, those two aspects are
>>> separable by using a typedef for a function's type.  The language
>>> linkage of the typedef determines the calling convention, while the
>>> language linkage of the function itself determines the name
>>> mangling.
>>
>> Can you illustrate how that would be done?  Since the language
>> linkage of a function is part of its type, it sounds like trying
>> to do such a thing would inevitably lead to undefined behavior.
>
> The language linkage of a function's type is indeed part of that type.  The
> language linkage of a function's name is not.  The standard's description of
> language linkage in 9.11p1 starts with the sentence "All function types,
> function names with external linkage, and variable names with external
> linkage have a language linkage.", clearly making the point that the
> language linkage of a function's type is a distinct thing from the language
> linkage of a function's name.  The standard could have inextricably linked
> them together - but it does not.  In fact, 9.11p5 includes an example
> demonstrating how they can be separated:
>
>     extern "C" typedef void FUNC();
>     FUNC f2;  // the name f2 has C ++ language linkage and the
>                      // function?s type has C language linkage
>
> [...]

Thank you for this citation.  It doesn't answer all my questions
but it certainly does provide an illuminating example.

It appears, however, that in practice there is no difference
between a type with a C language linkage and a C++ language
linkage.  Apparently most compilers ignore the distinction
because following the rules would break too much code.  Here
is a link to stackoverflow with more information:

    https://stackoverflow.com/questions/26647259/
            is-extern-c-a-part-of-the-type-of-a-function

[toc] | [prev] | [next] | [standalone]

#82646

On 12/14/21 6:21 PM, Tim Rentsch wrote:
> "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:
> 
>> On Wednesday, October 6, 2021 at 4:12:52 PM UTC-4, Tim Rentsch wrote:
>>
>>> James Kuyper <james...@alumni.caltech.edu> writes:
>>>
>>>> On 9/12/21 9:44 AM, Chris Vine wrote:
>>
>> ...
>>
>>>>> For functions, it does more than affecting naming.  The language
>>>>> linkage of a function determines two things:  the function's name
>>>>> (name mangling) and the function's type (calling convention).
>>>>
>>>> Furthermore, and not widely appreciated, those two aspects are
>>>> separable by using a typedef for a function's type.  The language
>>>> linkage of the typedef determines the calling convention, while the
>>>> language linkage of the function itself determines the name
>>>> mangling.
>>>
>>> Can you illustrate how that would be done?  Since the language
>>> linkage of a function is part of its type, it sounds like trying
>>> to do such a thing would inevitably lead to undefined behavior.
>>
>> The language linkage of a function's type is indeed part of that type.  The
>> language linkage of a function's name is not.  The standard's description of
>> language linkage in 9.11p1 starts with the sentence "All function types,
>> function names with external linkage, and variable names with external
>> linkage have a language linkage.", clearly making the point that the
>> language linkage of a function's type is a distinct thing from the language
>> linkage of a function's name.  The standard could have inextricably linked
>> them together - but it does not.  In fact, 9.11p5 includes an example
>> demonstrating how they can be separated:
>>
>>      extern "C" typedef void FUNC();
>>      FUNC f2;  // the name f2 has C ++ language linkage and the
>>                       // function?s type has C language linkage
>>
>> [...]
> 
> Thank you for this citation.  It doesn't answer all my questions
> but it certainly does provide an illuminating example.
> 
> It appears, however, that in practice there is no difference
> between a type with a C language linkage and a C++ language
> linkage.  Apparently most compilers ignore the distinction
> because following the rules would break too much code.  Here
> is a link to stackoverflow with more information:
> 
>      https://stackoverflow.com/questions/26647259/
>              is-extern-c-a-part-of-the-type-of-a-function
> 

Maybe a better way of saying that is most platform ABIs don't allow for 
a difference, because it would break too much existing code.

Few implementations are designed in a vacuum, most have an ABI they need 
to conform to (or multiple ones to select between with options).

Only when a brand new platform comes out do we have the ability to 
really inovate on an ABI, and even then inertia tends to restrict it.

[toc] | [prev] | [next] | [standalone]

#82653

Richard Damon <Richard@Damon-Family.org> writes:

> On 12/14/21 6:21 PM, Tim Rentsch wrote:
>
>> "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:
>>
>>> On Wednesday, October 6, 2021 at 4:12:52 PM UTC-4, Tim Rentsch wrote:
>>>
>>>> James Kuyper <james...@alumni.caltech.edu> writes:
>>>>
>>>>> On 9/12/21 9:44 AM, Chris Vine wrote:
>>>
>>> ...
>>>
>>>>>> For functions, it does more than affecting naming.  The language
>>>>>> linkage of a function determines two things:  the function's name
>>>>>> (name mangling) and the function's type (calling convention).
>>>>>
>>>>> Furthermore, and not widely appreciated, those two aspects are
>>>>> separable by using a typedef for a function's type.  The language
>>>>> linkage of the typedef determines the calling convention, while
>>>>> the language linkage of the function itself determines the name
>>>>> mangling.
>>>>
>>>> Can you illustrate how that would be done?  Since the language
>>>> linkage of a function is part of its type, it sounds like trying
>>>> to do such a thing would inevitably lead to undefined behavior.
>>>
>>> The language linkage of a function's type is indeed part of that
>>> type.  The language linkage of a function's name is not.  The
>>> standard's description of language linkage in 9.11p1 starts with
>>> the sentence "All function types, function names with external
>>> linkage, and variable names with external linkage have a language
>>> linkage.", clearly making the point that the language linkage of a
>>> function's type is a distinct thing from the language linkage of a
>>> function's name.  The standard could have inextricably linked them
>>> together - but it does not.  In fact, 9.11p5 includes an example
>>> demonstrating how they can be separated:
>>>
>>>      extern "C" typedef void FUNC();
>>>      FUNC f2;  // the name f2 has C ++ language linkage and the
>>>                       // function?s type has C language linkage
>>>
>>> [...]
>>
>> Thank you for this citation.  It doesn't answer all my questions
>> but it certainly does provide an illuminating example.
>>
>> It appears, however, that in practice there is no difference
>> between a type with a C language linkage and a C++ language
>> linkage.  Apparently most compilers ignore the distinction
>> because following the rules would break too much code.  Here
>> is a link to stackoverflow with more information:
>>
>>      https://stackoverflow.com/questions/26647259/
>>              is-extern-c-a-part-of-the-type-of-a-function
>
> Maybe a better way of saying that is most platform ABIs don't allow
> for a difference, because it would break too much existing code.

If the compiler had been doing its job all along then it wouldn't
break any code.  The whole point of having language linkage be
part of the type is to accommodate different ABIs for the two
languages, without having to worry about using the wrong one
because any violations would be caught by the type checker.

Furthermore, even if the ABIs are the same, the language standard
requires a diagnostic, so any C++ implementation should at least
give a warning.  If I give a -pedantic option then I expect
(wrongly it seems) that all language rules will be faithfully
observed.  Apparently -pedantic means "we're going to follow all
the rules that we think are worth following."  And to the best of
my knowledge clang is no better than gcc in this respect.  Very
disappointing.

[toc] | [prev] | [next] | [standalone]

#82647

On Tuesday, December 14, 2021 at 6:21:38 PM UTC-5, Tim Rentsch wrote:
> "james...@alumni.caltech.edu" <james...@alumni.caltech.edu> writes: 
...
> > The language linkage of a function's type is indeed part of that type. The 
> > language linkage of a function's name is not. The standard's description of 
> > language linkage in 9.11p1 starts with the sentence "All function types, 
> > function names with external linkage, and variable names with external 
> > linkage have a language linkage.", clearly making the point that the 
> > language linkage of a function's type is a distinct thing from the language 
> > linkage of a function's name. The standard could have inextricably linked 
> > them together - but it does not. In fact, 9.11p5 includes an example 
> > demonstrating how they can be separated: 
> > 
> > extern "C" typedef void FUNC(); 
> > FUNC f2; // the name f2 has C ++ language linkage and the
> > // function?s type has C language linkage 
> > 
> > [...] 
> 
> Thank you for this citation. It doesn't answer all my questions 
> but it certainly does provide an illuminating example.

If you can figure out words to express your remaining questions, I'd be curious
to find out what they are.
 
> It appears, however, that in practice there is no difference 
> between a type with a C language linkage and a C++ language 
> linkage. Apparently most compilers ignore the distinction 
> because following the rules would break too much code. Here 
> is a link to stackoverflow with more information: 
> 
> https://stackoverflow.com/questions/26647259/ 
> is-extern-c-a-part-of-the-type-of-a-function

The standard is quite clear: "Two function types with different language
linkages are distinct types even if they are otherwise identical." (9.11p1). I'm
annoyed, but unfortunately not surprised, to find that this has been ignored.
I've never had any need to write code where that issue would matter, which
is why I've never noticed.

[toc] | [prev] | [next] | [standalone]

#82649

On 15/12/2021 16:06, james...@alumni.caltech.edu wrote:
> On Tuesday, December 14, 2021 at 6:21:38 PM UTC-5, Tim Rentsch wrote:
>> "james...@alumni.caltech.edu" <james...@alumni.caltech.edu> writes:
> ...
>>> The language linkage of a function's type is indeed part of that type. The
>>> language linkage of a function's name is not. The standard's description of
>>> language linkage in 9.11p1 starts with the sentence "All function types,
>>> function names with external linkage, and variable names with external
>>> linkage have a language linkage.", clearly making the point that the
>>> language linkage of a function's type is a distinct thing from the language
>>> linkage of a function's name. The standard could have inextricably linked
>>> them together - but it does not. In fact, 9.11p5 includes an example
>>> demonstrating how they can be separated:
>>>
>>> extern "C" typedef void FUNC();
>>> FUNC f2; // the name f2 has C ++ language linkage and the
>>> // function?s type has C language linkage
>>>
>>> [...]
>>
>> Thank you for this citation. It doesn't answer all my questions
>> but it certainly does provide an illuminating example.
> 
> If you can figure out words to express your remaining questions, I'd be curious
> to find out what they are.
>   
>> It appears, however, that in practice there is no difference
>> between a type with a C language linkage and a C++ language
>> linkage. Apparently most compilers ignore the distinction
>> because following the rules would break too much code. Here
>> is a link to stackoverflow with more information:
>>
>> https://stackoverflow.com/questions/26647259/
>> is-extern-c-a-part-of-the-type-of-a-function
> 
> The standard is quite clear: "Two function types with different language
> linkages are distinct types even if they are otherwise identical." (9.11p1). I'm
> annoyed, but unfortunately not surprised, to find that this has been ignored.
> I've never had any need to write code where that issue would matter, which
> is why I've never noticed.

I have only used one compiler, Sun CC, that bothered to enforce the 
rule.  At the time, the main problem this caused me was it prevented 
static member functions being passed to pthread_create, I had to use 
extern "C" qualified friend function on Solaris.

-- 
Ian.

[toc] | [prev] | [next] | [standalone]

#82650

On 12/15/2021 4:14 PM, Ian Collins wrote:
> On 15/12/2021 16:06, james...@alumni.caltech.edu wrote:
>> On Tuesday, December 14, 2021 at 6:21:38 PM UTC-5, Tim Rentsch wrote:
>>> "james...@alumni.caltech.edu" <james...@alumni.caltech.edu> writes:
[...]
> I have only used one compiler, Sun CC, that bothered to enforce the 
> rule.  At the time, the main problem this caused me was it prevented 
> static member functions being passed to pthread_create, I had to use 
> extern "C" qualified friend function on Solaris.
> 

I remember that! I was using Solaris during Sun's CoolThreads contest.

[toc] | [prev] | [next] | [standalone]

#82656

Ian Collins <ian-news@hotmail.com> writes:

> On 15/12/2021 16:06, james...@alumni.caltech.edu wrote:
>
>> On Tuesday, December 14, 2021 at 6:21:38 PM UTC-5, Tim Rentsch wrote:
>>
>>> "james...@alumni.caltech.edu" <james...@alumni.caltech.edu> writes:
>>
>> ...
>>
>>>> The language linkage of a function's type is indeed part of
>>>> that type.  The language linkage of a function's name is not.
>>>> The standard's description of language linkage in 9.11p1 starts
>>>> with the sentence "All function types, function names with
>>>> external linkage, and variable names with external linkage have
>>>> a language linkage.", clearly making the point that the
>>>> language linkage of a function's type is a distinct thing from
>>>> the language linkage of a function's name.  The standard could
>>>> have inextricably linked them together - but it does not.  In
>>>> fact, 9.11p5 includes an example demonstrating how they can be
>>>> separated:
>>>>
>>>> extern "C" typedef void FUNC();
>>>> FUNC f2; // the name f2 has C ++ language linkage and the
>>>> // function?s type has C language linkage
>>>>
>>>> [...]
>>>
>>> Thank you for this citation.  It doesn't answer all my questions
>>> but it certainly does provide an illuminating example.
>>
>> If you can figure out words to express your remaining questions,
>> I'd be curious to find out what they are.
>>   >> It appears, however, that in practice there is no difference
>>
>>> between a type with a C language linkage and a C++ language
>>> linkage.  Apparently most compilers ignore the distinction
>>> because following the rules would break too much code.  Here
>>> is a link to stackoverflow with more information:
>>>
>>> https://stackoverflow.com/questions/26647259/
>>> is-extern-c-a-part-of-the-type-of-a-function
>>
>> The standard is quite clear:  "Two function types with different
>> language linkages are distinct types even if they are otherwise
>> identical."  (9.11p1).  I'm annoyed, but unfortunately not
>> surprised, to find that this has been ignored.  I've never had
>> any need to write code where that issue would matter, which is
>> why I've never noticed.
>
> I have only used one compiler, Sun CC, that bothered to enforce
> the rule.  At the time, the main problem this caused me was it
> prevented static member functions being passed to pthread_create,
> I had to use extern "C" qualified friend function on Solaris.

Did you try a pattern like this:

    extern "C" typedef void Whatsit( double * );

    class Foo {
      public:
        static Whatsit fred;
    };

    void
    Foo::fred( double *things ){
        for(  int i = 0;  i < 10;  i++  )  things[i] += i;
    }

This code is accepted by g++ back to -std=c++98.  Of course,
since we know the gnu tools are compromised that doesn't tell us
very much...

[toc] | [prev] | [next] | [standalone]

#82664

On 17/12/2021 01:37, Tim Rentsch wrote:
> Ian Collins <ian-news@hotmail.com> writes:
> 
>> On 15/12/2021 16:06, james...@alumni.caltech.edu wrote:
>>
>>> On Tuesday, December 14, 2021 at 6:21:38 PM UTC-5, Tim Rentsch wrote:
>>>
>>>> between a type with a C language linkage and a C++ language
>>>> linkage.  Apparently most compilers ignore the distinction
>>>> because following the rules would break too much code.  Here
>>>> is a link to stackoverflow with more information:
>>>>
>>>> https://stackoverflow.com/questions/26647259/
>>>> is-extern-c-a-part-of-the-type-of-a-function
>>>
>>> The standard is quite clear:  "Two function types with different
>>> language linkages are distinct types even if they are otherwise
>>> identical."  (9.11p1).  I'm annoyed, but unfortunately not
>>> surprised, to find that this has been ignored.  I've never had
>>> any need to write code where that issue would matter, which is
>>> why I've never noticed.
>>
>> I have only used one compiler, Sun CC, that bothered to enforce
>> the rule.  At the time, the main problem this caused me was it
>> prevented static member functions being passed to pthread_create,
>> I had to use extern "C" qualified friend function on Solaris.
> 
> Did you try a pattern like this:
> 
>      extern "C" typedef void Whatsit( double * );
> 
>      class Foo {
>        public:
>          static Whatsit fred;
>      };
> 
>      void
>      Foo::fred( double *things ){
>          for(  int i = 0;  i < 10;  i++  )  things[i] += i;
>      }
> 
> This code is accepted by g++ back to -std=c++98.  Of course,
> since we know the gnu tools are compromised that doesn't tell us
> very much...

No, I just used friend unctions, your suggestion would have been 
interesting to try, but I no longer have those tools installed.

-- 
Ian.

[toc] | [prev] | [next] | [standalone]

#82670

Ian Collins <ian-news@hotmail.com> writes:

> On 17/12/2021 01:37, Tim Rentsch wrote:
>
>> Ian Collins <ian-news@hotmail.com> writes:
>>
>>> On 15/12/2021 16:06, james...@alumni.caltech.edu wrote:
>>>
>>>> On Tuesday, December 14, 2021 at 6:21:38 PM UTC-5, Tim Rentsch wrote:
>>>>
>>>>> between a type with a C language linkage and a C++ language
>>>>> linkage.  Apparently most compilers ignore the distinction
>>>>> because following the rules would break too much code.  Here
>>>>> is a link to stackoverflow with more information:
>>>>>
>>>>> https://stackoverflow.com/questions/26647259/
>>>>> is-extern-c-a-part-of-the-type-of-a-function
>>>>
>>>> The standard is quite clear:  "Two function types with different
>>>> language linkages are distinct types even if they are otherwise
>>>> identical."  (9.11p1).  I'm annoyed, but unfortunately not
>>>> surprised, to find that this has been ignored.  I've never had
>>>> any need to write code where that issue would matter, which is
>>>> why I've never noticed.
>>>
>>> I have only used one compiler, Sun CC, that bothered to enforce
>>> the rule.  At the time, the main problem this caused me was it
>>> prevented static member functions being passed to pthread_create,
>>> I had to use extern "C" qualified friend function on Solaris.
>>
>> Did you try a pattern like this:
>>
>>      extern "C" typedef void Whatsit( double * );
>>
>>      class Foo {
>>        public:
>>          static Whatsit fred;
>>      };
>>
>>      void
>>      Foo::fred( double *things ){
>>          for(  int i = 0;  i < 10;  i++  )  things[i] += i;
>>      }
>>
>> This code is accepted by g++ back to -std=c++98.  Of course,
>> since we know the gnu tools are compromised that doesn't tell us
>> very much...
>
> No, I just used friend unctions, your suggestion would have been
> interesting to try, but I no longer have those tools installed.

Okay, thank you.  I was asking only out of curiosity.

[toc] | [prev] | [next] | [standalone]

#82655

"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:

> On Tuesday, December 14, 2021 at 6:21:38 PM UTC-5, Tim Rentsch wrote:
>
>> "james...@alumni.caltech.edu" <james...@alumni.caltech.edu> writes:
>
> ...
>
>>> The language linkage of a function's type is indeed part of that
>>> type.  The language linkage of a function's name is not.  The
>>> standard's description of language linkage in 9.11p1 starts with
>>> the sentence "All function types, function names with external
>>> linkage, and variable names with external linkage have a
>>> language linkage.", clearly making the point that the language
>>> linkage of a function's type is a distinct thing from the
>>> language linkage of a function's name.  The standard could have
>>> inextricably linked them together - but it does not.  In fact,
>>> 9.11p5 includes an example demonstrating how they can be
>>> separated:
>>>
>>> extern "C" typedef void FUNC();
>>> FUNC f2; // the name f2 has C ++ language linkage and the
>>> // function?s type has C language linkage
>>>
>>> [...]
>>
>> Thank you for this citation.  It doesn't answer all my questions
>> but it certainly does provide an illuminating example.
>
> If you can figure out words to express your remaining questions,
> I'd be curious to find out what they are.

At this point I'm not sure what the other questions are.  And since
I don't have any way to test various scenarios (or at least not any
convenient way), for now it seems best just to stop here.

>> It appears, however, that in practice there is no difference
>> between a type with a C language linkage and a C++ language
>> linkage.  Apparently most compilers ignore the distinction
>> because following the rules would break too much code.  Here
>> is a link to stackoverflow with more information:
>>
>> https://stackoverflow.com/questions/26647259/
>> is-extern-c-a-part-of-the-type-of-a-function
>
> The standard is quite clear:  "Two function types with different
> language linkages are distinct types even if they are otherwise
> identical."  (9.11p1).  [...]

Yes, I think that very sentence was quoted in the stackoverflow
page.

[toc] | [prev] | [next] | [standalone]

#81236

Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
> gcc allows you to pass a function pointer
> with C++ language linkage to a C function expecting a C function
> pointer, but strictly speaking it is undefined behaviour.

Does that mean that if you are using a C library and you give it a
function pointer (eg. a callback function), you ought to make that
function extern "C"?

How about std::qsort()? Does its comparator function pointer need to be
declared extern "C"? (Or does the standard require std::qsort() to be
usable with C++ function pointers directly?)

[toc] | [prev] | [next] | [standalone]

#81239

13.09.2021 08:34 Juha Nieminen kirjutas:
> Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
>> gcc allows you to pass a function pointer
>> with C++ language linkage to a C function expecting a C function
>> pointer, but strictly speaking it is undefined behaviour.
> 
> Does that mean that if you are using a C library and you give it a
> function pointer (eg. a callback function), you ought to make that
> function extern "C"?

Strictly speaking, yes, otherwise the calling conventions might be mixed 
up. But meanstream C++ implementations are using the same calling 
conventions for C and C++ code, so they don't mind.

> 
> How about std::qsort()? Does its comparator function pointer need to be
> declared extern "C"? (Or does the standard require std::qsort() to be
> usable with C++ function pointers directly?)

Indeed, the C++ standard requires qsort to accept both C and C++ 
callbacks. This is a copy-paste from N4842:

void qsort(void* base, size_t nmemb, size_t size, c-compare-pred * compar);
void qsort(void* base, size_t nmemb, size_t size, compare-pred * compar);

[toc] | [prev] | [next] | [standalone]

#81166

11.09.2021 13:35 Bonita Montero kirjutas:
> Is it specified that extern "C" functions never throw exceptions.

If the extern "C" function is itself compiled as C++, then you can 
freely throw exceptions inside it and in any C++ functions called from 
it, provided the exceptions are caught before propagating out of the 
extern "C" function. The latter is undefined behavior by the C++ 
standard. Some implementations define the behavior though, see the /EHa 
and /EHs options of MSVC or -fexceptions option for gcc.

So, for portability it is best to put a try-catch block around any 
extern "C" function contents, and to convert all exceptions into an 
error code return.

> If it is I see a problem with this: if I pass a function-pointer
> to a C++-function an extern "C" function and this function is
> called through its pointer by the extern "C" function it might
> throw an exception.

If you pass a pointer to a C++ function A to an extern "C" function B 
which is itself compiled as C++, then throwing an exception from A is 
not a problem if it is properly caught in B. Propagating the exception 
out of B is the problematic point.

[toc] | [prev] | [next] | [standalone]

#81252

On 9/11/2021 3:35 AM, Bonita Montero wrote:
> Is it specified that extern "C" functions never throw exceptions.
> If it is I see a problem with this: if I pass a function-pointer
> to a C++-function an extern "C" function and this function is
> called through its pointer by the extern "C" function it might
> throw an exception.

I can see how the following case might throw....

Disclaimer: I have no idea what the Standard says about it.


class C
{
     public:
        static void i_throw()
        {
            throw 1;
        }
};

extern "C" throwing_c_func()
{
     C::i_throw();
}

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c++

csiph-web