C++ Logo

SG12

Advanced search

Subject: Re: EWG Requests feedback/suggestions on Core Issue 1555
From: Richard Smith (richardsmith_at_[hidden])
Date: 2020-05-13 17:34:35


On Wed, May 13, 2020 at 3:29 PM Richard Smith <richardsmith_at_[hidden]>
wrote:

> On Wed, May 13, 2020 at 3:25 PM Richard Smith <richardsmith_at_[hidden]>
> wrote:
>
>> I don't feel like I have clarity on what EWG supports or does not support
>> changing here (neither from an implementer's perspective nor from the
>> perspective of a contributor to SG12).
>>
>> 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.
>>
>> The status quo in implementations is mostly that (1) is not implemented
>> for C language linkage, but that (2) is enforced for calling conventions
>> that are part of function types. And I expect every implementation has some
>> carve-outs for (3) in that they accept somewhat-different function types at
>> caller versus callee (for example, the pointee types of pointer parameters
>> may be permitted to vary in some ways).
>>
>> The only part of this that seems to obviously be in scope for SG12 is
>> point (3), but that's not where the problem lies. Making (3) be
>> conditionally-supported rather than UB does not address the issue, because
>> programs like
>>
>> extern "C" void f();
>> void g(void (*)());
>> int main() { g(f()); }
>>
>> ... would still be ill-formed due to the type mismatch from (1) + (2).
>> The implementations that ignore point (1) today would presumably still
>> ignore point (1) and accept the program (so we never reach (3) because the
>> types match). The implementations that implement point (1) today do so
>> because the types are meaningfully different, and so they would continue to
>> treat the call as UB.
>>
>> So any change to point (3) seems to be irrelevant if we don't also change
>> (1) or (2).
>>
>>
>> If we want to address this, it seems to me that we need to look at points
>> (1) and (2), which seem like EWG questions not SG12 questions to me. And it
>> sounds like the EWG telecon said that they're not prepared to make (1) or
>> (2) conditionally-supported (rejecting CWG's suggested approach), but might
>> be prepared to remove (some unspecified rule). So I think the leaves only a
>> few options:
>>
>> (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.
>>
>> Option (c) would result in an SG12 question (what should happen if you
>> implicitly convert a function pointer with one language linkage to a
>> function pointer with a different language linkage and try to call it?). Is
>> that what we're being asked? I think there's only one possible answer: that
>> is UB, at least for the implementations where it results in a different
>> calling convention. Making it conditionally-supported (or more concretely,
>> an implementation-defined choice of UB or as if the calling conventions
>> match) would mean it's still UB for code that wishes to be portable --
>> which seems like a regression, since such obviously-not-type-safe code used
>> to be ill-formed. The situation would be strictly better if we made point
>> (2) conditionally-supported instead: then the same code would still build
>> and work on the same targets, but on the targets where it doesn't work,
>> you'd get an error at compile time instead of UB at runtime.
>>
>> So I don't think there's anything that SG12 can do to avoid option (c)
>> being strictly worse than the "conditionally-supported" approach that EWG
>> already expressed a dislike for, and none of the other options are in
>> SG12's domain.
>>
>>
>> Given the above, I think realistically EWG needs to choose between (a)
>> (ie, all major implementations continue to ignore the standard rules), (b)
>> (ie, at least one target cannot implement the C++ rules without a severe
>> ABI break), conditionally-supported-(a) (which Hubert suggests was not
>> considered), or conditionally-supported-(b) (ie, what CWG asked for and EWG
>> said no to).
>>
>> To me it seems like (a) and (b) are not acceptable resolutions, and EWG
>> didn't like conditionally-supported-(b). So maybe we should be considering
>> conditionally-supported-(a) (which would simply be standardizing existing
>> practice).
>>
>
> Sorry, I messed up some labels here. I meant:
>
> """
> Given the above, I think realistically EWG needs to choose between (a)
> (ie, all major implementations continue to ignore the standard rules), (b)
> (ie, at least one target cannot implement the C++ rules without a severe
> ABI break), conditionally-supported-(b) (which Hubert suggests was not
> considered), or conditionally-supported-(c) (ie, what CWG asked for and EWG
> said no to).
>
> To me it seems like (a) and (b) are not acceptable resolutions, and EWG
> didn't like conditionally-supported-(b). So maybe we should be considering
> conditionally-supported-(c) (which would simply be standardizing existing
> practice).
> """
>

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

That is, the option I'm suggesting we consider is: declare that all the
current implementations are conforming in this regard (whether or not they
consider extern "C" to be part of the type), and they just need to document
that choice.

On Wed, May 13, 2020 at 1:11 PM Gabriel Dos Reis via SG12 <
sg12_at_[hidden]> wrote:

> My inclination would be to upgrade the behavior from UB to conditionally
>>> supported, but not further (e.g. no outright removal).
>>>
>>> -- Gaby
>>> ------------------------------
>>> *From:* SG12 <sg12-bounces_at_[hidden]> on behalf of Keane, Erich
>>> via SG12 <sg12_at_[hidden]>
>>> *Sent:* Wednesday, April 15, 2020 8:55:54 AM
>>> *To:* sg12_at_[hidden] <sg12_at_[hidden]>
>>> *Cc:* Keane, Erich <erich.keane_at_[hidden]>
>>> *Subject:* [SG12] EWG Requests feedback/suggestions on Core Issue 1555
>>>
>>>
>>> Hi SG12-
>>>
>>> In the EWG telecon today, we discussed core issue 1555 (
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#1555
>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fcwg_closed.html%231555&data=02%7C01%7Cgdr%40microsoft.com%7C0f2a8b0b3f754c1ea29c08d7f7786281%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637249968744430564&sdata=HXtvwaIBYHILQlUC%2BDEKrMXc2CC%2F0sE6n0ezz%2FvkxNA%3D&reserved=0>).
>>> The summary of the issue is that the standard makes function types of
>>> different language linkage incompatible, thus calling a function from a
>>> pointer with different language linkage is undefined behavior. One unnamed
>>> implementation was referenced during the discussion where language linkage
>>> effects calling convention.
>>>
>>>
>>>
>>> The major implementations (and none other than the 1 unnamed one listed)
>>> simply don’t implement this restriction (that the types aren’t compatible)
>>> because the calling convention is the same between the linkages.
>>>
>>>
>>>
>>> EWG was undecided as to whether we should remove this instance
>>> restriction, or leave it as undefined behavior. None seemed to support
>>> CWG1555’s proposed resolution of conditionally-supported behavior.
>>>
>>>
>>>
>>> (TL-DR people can start here😊 )
>>>
>>> The outcome of the discussion is that the impact and scope of this
>>> Undefined Behavior should be evaluated by SG12, and if possible, provide a
>>> set of recommendations for dealing with this core issue.
>>>
>>>
>>>
>>> -Erich
>>> _______________________________________________
>>> 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/0906.php
>>>
>>



SG12 list run by herb.sutter at gmail.com