Date: Thu, 23 May 2024 16:28:53 +0100
On Thu, 23 May 2024 at 13:58, Aaron Ballman via Liaison <
liaison_at_[hidden]> wrote:
> On Thu, May 23, 2024 at 7:55 AM Ville Voutilainen
> <ville.voutilainen_at_[hidden]> wrote:
> >
> > On Thu, 23 May 2024 at 14:47, Aaron Ballman via Liaison
> > <liaison_at_[hidden]> wrote:
> > >
> > > On Thu, May 23, 2024 at 7:24 AM Robert Seacord via Liaison
> > > <liaison_at_[hidden]> wrote:
> > > >
> > > > I cannot think of any reasons why this paper would cause any C/C++
> compatibility issues.
> > >
> > > Aside from it meaning these C interfaces are mandatory in C++ but
> > > optional in C. ;-)
> >
> > In <cstdint>, which is a C++ header and not a C header.
>
Just to be clear: if it's required to be present in <cstdint> then it's
also required to be present in the C++ version of <stdint.h>.
> >
> > I don't see a compatibility issue in this.
>
> Committee members sometimes understand that the `<cfoo>` headers are
> not feature-compatible with the <foo.h> headers in C; but my
> experience with users is that they don't always see that distinction
> so clearly. It's hard to explain to a user why:
>
> #include <stdint.h>
> intptr_t val;
>
> doesn't compile for them in C++ while
>
> #include <cstdint>
> intptr_t val;
>
> does,
That shouldn't happen (even ignoring the fact that the second example
doesn't use std::intptr_t, which I'm not sure is intentional or not, but
doesn't matter).
The contents of <cfoo> and <foo.h> should be the same **for anything that's
present in the C standard**. There are some C++-specific features like
std::lerp and std::nullptr_t for which things are a bit less clear:
https://cplusplus.github.io/LWG/issue3484
https://cplusplus.github.io/LWG/issue3799
https://cplusplus.github.io/LWG/issue3782
But since intptr_t is something specified in the C standard, nothing in the
C++ standard allows <stdint.h> and <cstdint> to be inconsistent about
whether they declare it.
> especially when C++ specifies that users who need their C++ code
> to compile with a C compiler should use the C headers. That's where I
> see the incompatibility. Also, WG14 rejected the paper because
> implementers said they couldn't support it (see the minutes of the
> discussion at https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3036.pdf)
> -- instead we put it into TS 6010 so we could explore in more detail
> whether it's possible to support. FWIW, Clang has no problems
> supporting mandatory intptr_t to my knowledge.
>
> ~Aaron
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2024/05/1414.php
>
liaison_at_[hidden]> wrote:
> On Thu, May 23, 2024 at 7:55 AM Ville Voutilainen
> <ville.voutilainen_at_[hidden]> wrote:
> >
> > On Thu, 23 May 2024 at 14:47, Aaron Ballman via Liaison
> > <liaison_at_[hidden]> wrote:
> > >
> > > On Thu, May 23, 2024 at 7:24 AM Robert Seacord via Liaison
> > > <liaison_at_[hidden]> wrote:
> > > >
> > > > I cannot think of any reasons why this paper would cause any C/C++
> compatibility issues.
> > >
> > > Aside from it meaning these C interfaces are mandatory in C++ but
> > > optional in C. ;-)
> >
> > In <cstdint>, which is a C++ header and not a C header.
>
Just to be clear: if it's required to be present in <cstdint> then it's
also required to be present in the C++ version of <stdint.h>.
> >
> > I don't see a compatibility issue in this.
>
> Committee members sometimes understand that the `<cfoo>` headers are
> not feature-compatible with the <foo.h> headers in C; but my
> experience with users is that they don't always see that distinction
> so clearly. It's hard to explain to a user why:
>
> #include <stdint.h>
> intptr_t val;
>
> doesn't compile for them in C++ while
>
> #include <cstdint>
> intptr_t val;
>
> does,
That shouldn't happen (even ignoring the fact that the second example
doesn't use std::intptr_t, which I'm not sure is intentional or not, but
doesn't matter).
The contents of <cfoo> and <foo.h> should be the same **for anything that's
present in the C standard**. There are some C++-specific features like
std::lerp and std::nullptr_t for which things are a bit less clear:
https://cplusplus.github.io/LWG/issue3484
https://cplusplus.github.io/LWG/issue3799
https://cplusplus.github.io/LWG/issue3782
But since intptr_t is something specified in the C standard, nothing in the
C++ standard allows <stdint.h> and <cstdint> to be inconsistent about
whether they declare it.
> especially when C++ specifies that users who need their C++ code
> to compile with a C compiler should use the C headers. That's where I
> see the incompatibility. Also, WG14 rejected the paper because
> implementers said they couldn't support it (see the minutes of the
> discussion at https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3036.pdf)
> -- instead we put it into TS 6010 so we could explore in more detail
> whether it's possible to support. FWIW, Clang has no problems
> supporting mandatory intptr_t to my knowledge.
>
> ~Aaron
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2024/05/1414.php
>
Received on 2024-05-23 15:30:13