C++ Logo


Advanced search

Re: [SG12] EWG Requests feedback/suggestions on Core Issue 1555

From: Richard Smith <richardsmith_at_[hidden]>
Date: Thu, 14 May 2020 01:00:47 -0700
On Wed, 13 May 2020, 22:22 Ville Voutilainen, <ville.voutilainen_at_[hidden]>

> 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.)

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.)


Received on 2020-05-14 03:04:01