> On May 14, 2020, at 7:11 PM, JF Bastien <cxx_at_[hidden]> wrote:
>
> On Thu, May 14, 2020 at 11:18 AM David Vandevoorde via SG12 <sg12_at_[hidden] <mailto:sg12_at_[hidden]>> wrote:
>
>
>> On May 14, 2020, at 1:46 PM, Richard Smith <richardsmith_at_[hidden] <mailto:richardsmith_at_[hidden]>> wrote:
>>
>> On Thu, 14 May 2020, 09:57 David Vandevoorde, <daveed_at_[hidden] <mailto:daveed_at_[hidden]>> wrote:
>>
>>
>>> On May 14, 2020, at 4:00 AM, Richard Smith via SG12 <sg12_at_[hidden] <mailto: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 don’t know. I _suspect_ that the underlying calling conventions are actually identical in most or all cases, but we only deal with the front end aspects (types, in this case).

 Daveed

>
> 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] <mailto:SG12_at_[hidden]>
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg12 <https://lists.isocpp.org/mailman/listinfo.cgi/sg12>
> Link to this post: http://lists.isocpp.org/sg12/2020/05/0919.php <http://lists.isocpp.org/sg12/2020/05/0919.php>