[Bug bootstrap/107795] <limits.h> recursion through <syslimits.h> breaks non-GNU implementations of the C++ stdlib

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107795

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Louis Dionne from comment #4)
> (In reply to Andrew Pinski from comment #2)
> > You should not be building on top of GCC's limits.h header at all really.
> > Rather implementations should have their own.
> 
> What do you mean by "implementations"? Do you mean implementations of the C
> library or compiler implementations, or what?

GCC limits.h is the implementation detail of GCC.
Yes I know it gets fuzzy. This is why GCC even has fixincludes to make sure
target headers are always correct. See the comment I posted.
If clang/libc++ wants built on top of GCC's implementation of GCC's C
implementation, then it will need to similar tricks as GCC does for other
targets. GCC does fixincludes trick to support other targets besides Linux
even.

> 
> 
> (In reply to Jonathan Wakely from comment #3)
> > (In reply to Andrew Pinski from comment #2)
> > > Rather implementations should have their own.
> > 
> > Or just use GCC's one without change, which is what libstdc++ does. We don't
> > provide any <limits.h> in libstdc++, only <climits>. When you #include
> > <limits.h> with G++ you just get GCC's own <limits.h> as-is.
> 
> Yeah but we may need to add stuff to <limits.h> on some platforms, so we may
> need to have such a header. Also, I assume you only do that for a subset of
> headers, because you must have <foo.h> headers in libstdc++ for a few
> headers that require adding const-correct overloads of e.g. `memchr`?

Yes and some targets such as solaris even includes some of those inside foo.h
... GCC's libstdc++ had issues with that previous and needed some changes.