We have not received such a paper, no.

On Mon, Oct 19, 2020 at 10:37 AM Gabriel Dos Reis <gdr_at_[hidden]> wrote:

> 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_[hidden]
> *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]> wrote:
>
>
>
>
>
> On Thu, May 14, 2020 at 6:21 PM Gabriel Dos Reis <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]> *On Behalf Of *JF Bastien
> via SG12
> *Sent:* Thursday, May 14, 2020 4:11 PM
> *To:* sg12_at_[hidden]
> *Cc:* JF Bastien <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]> wrote:
>
>
>
>
>
> On May 14, 2020, at 1:46 PM, Richard Smith <richardsmith_at_[hidden]>
> wrote:
>
>
>
> On Thu, 14 May 2020, 09:57 David Vandevoorde, <daveed_at_[hidden]> wrote:
>
>
>
>
>
> On May 14, 2020, at 4:00 AM, Richard Smith via SG12 <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]
> 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>
>
>