Provide stdint.h macros unconditionally

[nikolasklauser_berlin.de]

Summary

upstream libc++ has removed stdint.h. However, this was partially reverted for FreeBSD because some macros have been removed in C++03 mode. This updates the libc headers to provide these macros in C++ unconditionally as well and undoes the revert.

[brooks]

How does this interact with an older, stock LLVM that provides stdint.h?

[nikolasklauser_berlin.de]

In D56746#1299709, @brooks wrote:

How does this interact with an older, stock LLVM that provides stdint.h?

It doesn't make a difference. The old stdint.h from libc++ simply defined the macros unconditionally that aren't checked anymore with this patch.

[dim]

https://sourceware.org/bugzilla/show_bug.cgi?id=15366 and https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=1ef74943ce2f114c78b215af57c2ccc72ccdb0b7 provide some context. In glibc's case, they simply dropped the conditionals in 2013, and it doesn't seem to have resulted in a lot of problems.

The problems I encountered in ports while evaluating the llvm 21 update https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292067 were typically old ports that use -std=gnu++98, and those would then fail with things like SIZE_MAX being undefined, etc.

[imp]

So the history:

ISO/IEC 9899:1999 Section 7.18 (Integer types <stdint.h>):
Footnote 219 (regarding limit macros like INT32_MAX):
"C++ implementations should define these macros only when __STDC_LIMIT_MACROS is defined before <stdint.h> is included."
Footnote 222 (regarding constant macros like INT32_C):
"C++ implementations should define these macros only when __STDC_CONSTANT_MACROS is defined before <stdint.h> is included."
(emphasis mine)

C++03 did not include <stdint.h> or <cstdint> at all, making it implementation defined. C11 removed these footnotes because C++11 requires that <cstdint> provides all the definitions unconditionally.

I think we should just kill these. NetBSD added || __cplusplus >= 2011xx to take into account the C++ standard. That's pedantically correct, but since the footnote is a SHOULD in a C standard about C++, I think we'd be on solid ground to just remove them like this commit does. It also matches what glibc did:
https://sourceware.org/bugzilla/show_bug.cgi?id=15366
Since the C standard cannot be normative about what C++ compilers do and the footnote was a 'SHOULD' not a 'MUST' (though C99 didn't follow the SHOULD MUST MAY RFC)

Also, upstream is explicitly not supporting C++ before c++11, IIRC, so that signals we'd be hard pressed to provide a conformant C++03 or c++98 environment anyway. And there's no c++03 didn't bump the cplusplus value, so we can't easily distinguish anyway.

[dim]

I noticed that sys/arm64/include/_stdint.h is missing from this diff, and we also still have in sys/sys/cdefs.h:

/* C++11 exposes a load of C99 stuff */
#if defined(__cplusplus) && __cplusplus >= 201103L
#define __LONG_LONG_SUPPORTED
#ifndef __STDC_LIMIT_MACROS
#define __STDC_LIMIT_MACROS
#endif
#ifndef __STDC_CONSTANT_MACROS
#define __STDC_CONSTANT_MACROS
#endif
#endif

Either we always define these for __cplusplus (regardless of the version) or we could maybe delete the whole block?

[dim]

Btw I intend to commit this in two parts: first the changes to the system headers, then a revert of the llvm-project revert. :)

[dim]

And after this, I can also get rid of rG3cdb6c9d92ecf479a0df338267f3f844ef6feeb2, which added STDC_CONSTANT_MACROS and STDC_LIMIT_MACROS to libc++'s <inttypes.h>.

Note that there are also a few instances of similar checking code in contrib/llvm-project/libcxx/include/__cxx03, but it's probably better to leave those alone. (Upstream also considers these frozen, except for possible security issues.)