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

Hmm, that would be making a recommended practice for ABI matters that we have less understanding or expertise on as a collective bunch.

-- Gaby


From: SG12 <sg12-bounces_at_[hidden]<mailto:sg12-bounces_at_[hidden]>> On Behalf Of Richard Smith via SG12
Sent: Thursday, May 14, 2020 10:46 AM
To: David Vandevoorde <daveed_at_[hidden]<mailto:daveed_at_[hidden]om>>
Cc: Richard Smith <richardsmith_at_[hidden]<mailto:richardsmith_at_[hidden]>>; sg12_at_[hidden]<mailto:sg12_at_[hidden]>
Subject: Re: [SG12] EWG Requests feedback/suggestions on Core Issue 1555

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

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

Daveed