On Thu, May 14, 2020 at 11:18 AM David Vandevoorde via SG12 <
sg12_at_[hidden]> wrote:

>
>
> On May 14, 2020, at 1:46 PM, Richard Smith <richardsmith_at_[hidden]>
> wrote:
>
> On Thu, 14 May 2020, 09:57 David Vandevoorde, <daveed_at_[hidden]> wrote:
>
>>
>>
>> On May 14, 2020, at 4:00 AM, Richard Smith via SG12 <
>> sg12_at_[hidden]> wrote:
>>
>> [ About language linkage being part of function types…]
>>
>> I hope someone who maintains an implementation for such a target will
>> speak up. (I think someone did when this was last asked, though, so I don't
>> think this is a theoretical or legacy concern. I'd be very happy to be
>> wrong about that.)
>>
>>>
>> Our front end can be configured in this respect:
>> - Whether C and C++ language linkage function types are distinct
>> - If they are not distinct, whether they can be implicitly converted
>> from one to another
>> (and some added configurability to decide whether those implicit
>> conversions are
>> enabled by default or require a command-line option)
>>
>> For those customers who have shared they configurations with us, most
>> appear to keep the types distinct but allow implicit conversions between
>> them. So the following example is accepted:
>>
>> $ cat -> r.cpp
>> extern "C" typedef int F(void);
>> extern "C++" typedef int FPP(void);
>>
>> constexpr int g(F) { return 1; }
>> constexpr int g(FPP) { return 2; };
>>
>> F f;
>> FPP fpp;
>> F *pf = fpp;
>>
>> static_assert(g(f) == 1);
>> static_assert(g(fpp) == 2);
>> $ ./cfe --c++20 r.cpp
>> $
>>
>>
>> (The “major” implementations would complain g has a duplicate definition.)
>>
>
> So, if we want to make all known implementations conforming, we would need
> to make both (1) and (2) conditionally supported. Right?
>
>
> Probably. That said, none of the configuration files I had access to made
> types distinct and disallowed conversions. I.e., either language linkage
> did not affect function types, or they did but you could convert pointers
> to C-functions to pointers to C++-functions (and v.v.; suggesting that it’s
> only a type system feature, not a calling convention feature). (But to be
> sure, the configurations I checked do not represent all our customers.)
>

Does the implicit conversion create a thunk?

I was talking to a coworker about this issue, and he agrees with Richard's
analysis, saying:

   - If the language calling conventions are actually different, the
   function types must be different, wrongly-matched calls must have UB, and
   implicit conversion really ought to be disallowed.
   - If the conventions are never permitted to be different, there is no
   good reason not to unify the types everywhere.
   - If the conventions are permitted to be different, the types can either
   be kept formally different everywhere or be allowed to be unified as an
   implementation decision.
   - If the committee chooses to unify the types everywhere, some
   implementors will be forced to either ignore it or break ABI and
   (potentially) source compatibility. I assume they will all choose to
   ignore it.
   - If the committee chooses to make the types different everywhere, some
   implementors will be forced to either ignore it or break both source
   compatibility and ABI. I assume they will all choose to ignore it, just as
   they have for the last 25 years.
   - If the committee chooses to make it implementation-defined, they will
   bless the status quo and formalize language divergence on different targets.
   - If the committee tries to thread the needle and make the types
   different but allow implementations to make the types implicitly
   interconvertible, they will be ignored *and* formalize language divergence
   on different targets.

I would strongly encourage making it implementation-defined with an eye
towards formalizing the treatment of calling conventions in the language.
That is, formalize it as “function types carry a calling convention; it is
implementation-defined whether the current language linkage changes that
convention; here is how different calling conventions affect the language”.



I'd be less happy with that than with making only one of the two options
> conditionally-supported, but maybe it's the right choice, given that
> changing only (2) would require an ABI break for major implementations to
> conform, and changing only (1) would be a source-level break for Daveed's
> customers described above -- that is, for the people who were trying to
> follow our rules as best as they could even though their C and C++
> functions had the same calling convention.
>
> (Also, it sounds like there are not just one or two targets like this,
> given Hubert's report and Daveed's multiple customers. I'm guessing the
> latter implementations are things like processor-specific compilers in the
> embedded space or similar, which I think generally have less representation
> on the committee.)
>
>
> Right.
>
> Now we have "Recommended behavior" as a tool, we could make (1)
> conditionally supported, with a recommendation that C language linkage
> result in the same type as C++ language linkage, and make (2) conditionally
> supported, with a recommendation to allow conversion if the calling
> convention would be the same (for those that didn't follow our first
> recommendation).
>
>
> That sounds reasonable to me.
>
> Daveed
>
>
> _______________________________________________
> SG12 mailing list
> SG12_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg12
> Link to this post: http://lists.isocpp.org/sg12/2020/05/0919.php
>