[libc-commits] [libc] [libc] force GCC limits.h to not include_next limits.h (PR #79211)

[via libc-commits]

lntue wrote:


> > The idea was that we can't control GCC, so we'd do it in a header.
> 
> That's another approach we could take, which #78887 very nearly does, except:
> 
> 1. it still uses `include_next` to include...who knows what (include_next depends on the compiler search path at compile time)...
> 2. it doesn't remove existing users of `<limits.h>`
> 
> I think I'd be ok with that approach if 1 and 2 were addressed as well in the same PR. (or a good reason for NOT doing either was provided)

I could definitely include 2 to #78887.  On the other hand, the main reason I added `#include_next <limits.h>` just in-case they the environment headers provide other extra macros that we don't have (yet).  We can remove the `#include_next` there if you think it is unnecessary. 

> Personally, I have a weak preference for "relying on the compiler (and it's resource dir)" a la this PR. But I could be convinced to not use ANY external dependency and just define these ourselves.
> 
> FWIW, clang's preprocessor also generates some of these defines. Example:
> 
> https://github.com/llvm/llvm-project/blob/a16f81f5e3313e88f96de35e5edfe8bee463d308/clang/lib/Frontend/InitPreprocessor.cpp#L1014-L1071
> 
> 
> (besides the header file I linked to above)

Clang and GCC both provide various of those definitions, but which ones they provide do vary depending on their versions and the platforms.  So I think we can use C23-compliance as a reason and a selling point to just provide a complete `limits.h` header, consistent across compilers+versions+supported platforms?

There is only 1 constant that confuses me is `MB_LEN_MAX`, which seems to be 1 for clang's header, 16 for glibc, and 4 for musl...

https://github.com/llvm/llvm-project/pull/79211