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

[Nick Desaulniers via libc-commits]

nickdesaulniers wrote:

> 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.

More specifically, I worry about `include_next` is even referring to, particularly if it's glibc's limits.h.  Then we're mixing our headers with glibc's. Perhaps that unavoidable for full build mode.

If you remove `#include_next <limits.h>` from https://github.com/llvm/llvm-project/pull/78887, does it still work? If so, let's remove it, just so we have certainty about what's getting included at runtime.

As for other extra macros; I'd kind of like to know what they are (if any).  I think it's better to exclude them for now, then add them when we observed an issue specific to no including them.  Then we can have well formed justification for why we include them, rather than pull in headers based on the hope that they contain something that might be helpful (but who knows what else).

> 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...

Does `MB` stand for multi-byte characters?  Sticking to the point above, I don't mind leaving it out until it becomes a problem. That can get fixed then. Right now, I think it's just some of the `LLONG_MAX` integer macros that are used in our tests that are relevant to our current use cases.  We can fix that in the future when we have more customers interested in multi-byte char support.

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