Date: Thu, 23 May 2024 20:56:11 +0300
On Thu, 23 May 2024 at 20:18, Ville Voutilainen
<ville.voutilainen_at_[hidden]> wrote:
>
> On Thu, 23 May 2024 at 18:30, Jonathan Wakely <cxx_at_[hidden]> wrote:
> >> > 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>.
>
> You're citing the general rule, which can have specific exceptions,
> and this proposal does carve exactly such an exception
> in its wording. So, as proposed, this proposal requires [u]intptr_t in
> <cstdint>, but not in the C++ version of <stdint.h>.
..except it doesn't, because there's a general rule in
[support.c.headers.other]/1 that gives stdint.h the same contents
with different namespacing.
Still not a compatibility issue. You compile as C++, you get more
guarantees. If you use those additional guarantees
and your code no longer compiles as C, your problem.
<ville.voutilainen_at_[hidden]> wrote:
>
> On Thu, 23 May 2024 at 18:30, Jonathan Wakely <cxx_at_[hidden]> wrote:
> >> > 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>.
>
> You're citing the general rule, which can have specific exceptions,
> and this proposal does carve exactly such an exception
> in its wording. So, as proposed, this proposal requires [u]intptr_t in
> <cstdint>, but not in the C++ version of <stdint.h>.
..except it doesn't, because there's a general rule in
[support.c.headers.other]/1 that gives stdint.h the same contents
with different namespacing.
Still not a compatibility issue. You compile as C++, you get more
guarantees. If you use those additional guarantees
and your code no longer compiles as C, your problem.
Received on 2024-05-23 17:56:24