On Thu, May 14, 2020 at 4:01 AM Richard Smith via SG12 <
sg12_at_[hidden]> wrote:

> On Wed, 13 May 2020, 22:22 Ville Voutilainen, <ville.voutilainen_at_[hidden]>
> wrote:
>
>> On Thu, 14 May 2020 at 01:35, Richard Smith via SG12
>> <sg12_at_[hidden]> wrote:
>> >>> The status quo in the standard is:
>> >>> 1) Language linkage is part of the function type.
>> >>> 2) Initializing a function pointer with a wrong-language-linkage
>> function (pointer) is a type error.
>> >>> 3) Explicitly casting a function pointer to the wrong type and
>> calling it is UB.
>>
>
> 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.)
>
I work in the vicinity of such an implementation. The cost to removing (1)
is non-zero for "C" language linkage, and I am not sufficiently familiar
with the nuances of the implementation to know how expensive migrating code
would be if a change was made from the status quo in the standard. Removing
(1) for other language linkages, of which the implementation supports
several, is a non-starter. In particular, the implementation does use
language linkage to indicate differences in calling convention, and
interfacing with code implemented with different calling conventions is
common in the context of the platform (due to a large body of non-C system
APIs and object-code-only libraries built against older ABI levels).