On Thu, 14 May 2020 at 11:01, Richard Smith <richardsmith_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.
>>
>> >>> (a) the status quo: the standard continues to say the same thing and vendors continue to ignore it,
>> >>> (b) we remove point (1) above and break the targets relying on it, or
>> >>> (c) we remove point (2) above.
>> > Wow, this is embarrassing, that's still wrong. Should be:
>> > """
>> > To me it seems like (a) and (b) are not acceptable resolutions, and EWG didn't like conditionally-supported-(c). So maybe we should be considering conditionally-supported-(b) (which would simply be standardizing existing practice).
>> > """
>>
>> Funny. From a programmer perspective, I would prefer removing all of
>> points 1, 2, and 3. I may be wrong,
>> but removing point 1 seems to result in points 2 and 3 being removed.
>
>
> That's option (b). Removing point 1 does remove point 2 but not 3 as presented: there are other ways the type can differ. (But yes, it would define away the language linkage part of point 3.)

Oops, sorry, I was reading all this in a very myopic(*) fashion, I
didn't realize that (3) is more general than just
the linkage difference. I have no intention of removing (3)
altogether; calling a function that takes or returns
8 bytes through a pointer to a function that takes or returns 4 bytes
will smash my program, I am not suggesting
that we waste any time making that not UB.

(*) And I don't mean I read it without my glasses. :)

>> If I program with the false hope that 1/2/3 don't exist, what target
>> platforms is my code currently not portable to?
>> What platforms is it portable to?
> 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.)

What concerns me here is compatibility expectations with extern "C"
code, like, well, C code. The lambda workaround
seems like it works, but it seems unfortunate that I'd have to Wrap
That Hard to take an address of a C function and
use it in things like.. ..std::function.