https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107795
--- Comment #8 from Louis Dionne <ldionne.2 at gmail dot com> --- (In reply to Andrew Pinski from comment #5) > (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. When compiling pure C with GCC, what's the order of includes? Is it "C Library includes > GCC builtin includes", or "GCC builtin includes > C Library includes"? > 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. That's exactly my point -- this bug report is about removing the need to do tricks just to build on top of GCC's <limits.h>. None of the other headers require it AFAICT, so why does this header require it? Is there a reason not to make GCC's <limits.h> friendly to #include_next?
