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]p.org <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