I don’t remember if we finally got a paper on the issue as suggested below? -- Gaby


From: JF Bastien <cxx_at_[hidden]>
Sent: Monday, October 19, 2020 10:05 AM
To: Gabriel Dos Reis <gdr_at_[hidden]>
Cc: sg12_at_lists.isocpp.org
Subject: Re: [SG12] EWG Requests feedback/suggestions on Core Issue 1555

Hi folks,

I'd like to resolve this issue. We don't currently seem to have SG12 consensus on the resolution. Would EWG discuss this specific issue, or can we resolve SG12 concerns on this mailing list?

Thanks,

JF

On Thu, May 14, 2020 at 6:24 PM JF Bastien <cxx_at_[hidden]<mailto:cxx_at_[hidden]>> wrote:


On Thu, May 14, 2020 at 6:21 PM Gabriel Dos Reis <gdr_at_[hidden]<mailto:gdr_at_[hidden]>> wrote:


  * That is, formalize it as “function types carry a calling convention; it is implementation-defined whether the current language linkage changes that convention; here is how different calling conventions affect the language”.

Which is close to what MSVC has been doing for its other calling conventions (not “C” though).
Calling conventions are a reality that is unteanable to ignore…

Right! I remember that you have a few calling conventions. Googling finds:

https://docs.microsoft.com/en-us/cpp/cpp/calling-conventions?view=vs-2019<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fcpp%2Fcpp%2Fcalling-conventions%3Fview%3Dvs-2019&data=04%7C01%7Cgdr%40microsoft.com%7Cbdfd3bd9320849a3297908d874512496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637387239152964191%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tTtjj6amSN25KpEnCD3ntTOOt97xU%2Fb%2FX7wUj6p2VPk%3D&reserved=0>

I guess we need a paper exploring this further. It would be helpful to get SG12’s input before writing a paper. What would you recommend as an approach?


-- Gaby

From: SG12 <sg12-bounces_at_[hidden]<mailto:sg12-bounces_at_[hidden]>> On Behalf Of JF Bastien via SG12
Sent: Thursday, May 14, 2020 4:11 PM
To: sg12_at_[hidden]<mailto:sg12_at_[hidden]>
Cc: JF Bastien <cxx_at_[hidden]om<mailto:cxx_at_[hidden]>>
Subject: Re: [SG12] EWG Requests feedback/suggestions on Core Issue 1555

On Thu, May 14, 2020 at 11:18 AM David Vandevoorde via SG12 <sg12_at_[hidden]<mailto:sg12_at_[hidden]>> wrote:


On May 14, 2020, at 1:46 PM, Richard Smith <richardsmith_at_[hidden]<mailto:richardsmith_at_[hidden]>> wrote:

On Thu, 14 May 2020, 09:57 David Vandevoorde, <daveed_at_[hidden]<mailto:daveed_at_[hidden]>> wrote:


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

[ About language linkage being part of function types…]
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.)

Our front end can be configured in this respect:
  - Whether C and C++ language linkage function types are distinct
  - If they are not distinct, whether they can be implicitly converted from one to another
    (and some added configurability to decide whether those implicit conversions are
     enabled by default or require a command-line option)

For those customers who have shared they configurations with us, most appear to keep the types distinct but allow implicit conversions between them. So the following example is accepted:

$ cat -> r.cpp
extern "C" typedef int F(void);
extern "C++" typedef int FPP(void);

constexpr int g(F) { return 1; }
constexpr int g(FPP) { return 2; };

F f;
FPP fpp;
F *pf = fpp;

static_assert(g(f) == 1);
static_assert(g(fpp) == 2);
$ ./cfe --c++20 r.cpp
$

(The “major” implementations would complain g has a duplicate definition.)

So, if we want to make all known implementations conforming, we would need to make both (1) and (2) conditionally supported. Right?

Probably. That said, none of the configuration files I had access to made types distinct and disallowed conversions. I.e., either language linkage did not affect function types, or they did but you could convert pointers to C-functions to pointers to C++-functions (and v.v.; suggesting that it’s only a type system feature, not a calling convention feature). (But to be sure, the configurations I checked do not represent all our customers.)

Does the implicit conversion create a thunk?

I was talking to a coworker about this issue, and he agrees with Richard's analysis, saying:

  * If the language calling conventions are actually different, the function types must be different, wrongly-matched calls must have UB, and implicit conversion really ought to be disallowed.
  * If the conventions are never permitted to be different, there is no good reason not to unify the types everywhere.
  * If the conventions are permitted to be different, the types can either be kept formally different everywhere or be allowed to be unified as an implementation decision.
  * If the committee chooses to unify the types everywhere, some implementors will be forced to either ignore it or break ABI and (potentially) source compatibility. I assume they will all choose to ignore it.
  * If the committee chooses to make the types different everywhere, some implementors will be forced to either ignore it or break both source compatibility and ABI. I assume they will all choose to ignore it, just as they have for the last 25 years.
  * If the committee chooses to make it implementation-defined, they will bless the status quo and formalize language divergence on different targets.
  * If the committee tries to thread the needle and make the types different but allow implementations to make the types implicitly interconvertible, they will be ignored *and* formalize language divergence on different targets.
I would strongly encourage making it implementation-defined with an eye towards formalizing the treatment of calling conventions in the language.
That is, formalize it as “function types carry a calling convention; it is implementation-defined whether the current language linkage changes that convention; here is how different calling conventions affect the language”.



I'd be less happy with that than with making only one of the two options conditionally-supported, but maybe it's the right choice, given that changing only (2) would require an ABI break for major implementations to conform, and changing only (1) would be a source-level break for Daveed's customers described above -- that is, for the people who were trying to follow our rules as best as they could even though their C and C++ functions had the same calling convention.

(Also, it sounds like there are not just one or two targets like this, given Hubert's report and Daveed's multiple customers. I'm guessing the latter implementations are things like processor-specific compilers in the embedded space or similar, which I think generally have less representation on the committee.)

Right.

Now we have "Recommended behavior" as a tool, we could make (1) conditionally supported, with a recommendation that C language linkage result in the same type as C++ language linkage, and make (2) conditionally supported, with a recommendation to allow conversion if the calling convention would be the same (for those that didn't follow our first recommendation).

That sounds reasonable to me.

Daveed


_______________________________________________
SG12 mailing list
SG12_at_[hidden]g<mailto:SG12_at_[hidden]>
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg12<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg12&data=04%7C01%7Cgdr%40microsoft.com%7Cbdfd3bd9320849a3297908d874512496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637387239152964191%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5n3M0suiCRhtSccDCE%2F6qD1a0HoGDJdrKJ8eRhqRaMg%3D&reserved=0>
Link to this post: http://lists.isocpp.org/sg12/2020/05/0919.php<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fsg12%2F2020%2F05%2F0919.php&data=04%7C01%7Cgdr%40microsoft.com%7Cbdfd3bd9320849a3297908d874512496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637387239152974140%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lj7%2Bpa1P3SdqogWLgwh8GVC5DvJj5T0lTo7im3h7d9k%3D&reserved=0>