include_next of limits.h still broken

[Quuxplusone]

Bugzilla Link	PR27001
Status	NEW
Importance	P normal
Reported by	Hans-Bernhard Broeker (HBBroeker@T-Online.de)
Reported on	2016-03-19 15:48:08 -0700
Last modified on	2018-01-16 10:51:50 -0800
Version	3.7
Hardware	PC Windows XP
CC	anton@korobeynikov.info, f.aurich@technisat.de, llvm-bugs@lists.llvm.org, richard-llvm@metafoo.co.uk
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also

The issue described in Bug ID 6379 about 6 years ago is still (or again?)
present in version 3.7.1 on Cygwin.  I'd try to re-open that one, but since it
was for Linux, and this isn't, I'm filing a new one.

A source containing just

#include <dirent.h>

fails to compile using clang on current Cygwin, because it doesn't find
NAME_MAX.  The problem is, just as described in 6379, that this mechanism in
clang's <limits.h>:

/* The system's limits.h may, in turn, try to #include_next GCC's limits.h.
   Avert this #include_next madness. */
#if defined __GNUC__ && !defined _GCC_LIMITS_H_
#define _GCC_LIMITS_H_
#endif

causes the subsequent #include_next<limits.h>, which pulls in GCC's version, to
expand to nothing.  Unfortunately, this mean the actual system <limits.h> is
never included, because that would have been done from inside GCC's one.
Here's a preprocessed source excerpt of how it's supposed to be (indented by
hand, for clarity):

 #  1 "/usr/bin/../lib/clang/3.7.1/include/limits.h" 1 3 4
 # 39 "/usr/bin/../lib/clang/3.7.1/include/limits.h" 3 4
  #  1 "/usr/lib/gcc/i686-pc-cygwin/5.3.0/include/limits.h" 1 3 4
  # 34 "/usr/lib/gcc/i686-pc-cygwin/5.3.0/include/limits.h" 3 4
   # 1 "/usr/lib/gcc/i686-pc-cygwin/5.3.0/include/syslimits.h" 1 3 4

    #  1 "/usr/include/limits.h" 1 3 4
    # 14 "/usr/include/limits.h" 3 4
     # 1 "/usr/include/features.h" 1 3 4
    # 15 "/usr/include/limits.h" 2 3 4
   #  8 "/usr/lib/gcc/i686-pc-cygwin/5.3.0/include/syslimits.h" 2 3 4
  # 35 "/usr/lib/gcc/i686-pc-cygwin/5.3.0/include/limits.h" 2 3 4
 # 40 "/usr/bin/../lib/clang/3.7.1/include/limits.h" 2 3 4
# 17 "/usr/include/sys/dirent.h" 2 3 4

With the above code snippet active, this ends at gcc's <limits.h>, so it never
reaches /usr/include/limits.h, and thus fails to find NAME_MAX defined there.

As I see it, that "Avert ... madness" mechanism is a badly planned hack which
does exactly the wrong thing on any platform where GCC is the primary compiler
(Linux, Cygwin, MinGW, ...).

As to Bug 6379, I have no idea how that could have been marked "closed", given
that the problematic code sequence is still present today, the proposed fix was
never applied, nor could the actual issue be considered "fixed".

[Quuxplusone]

GCC's builtin headers should not be in your heater search path at all. Are you explicitly specifying them, or is clang's driver erroneously adding them for you?

[Quuxplusone]

(In reply to comment #1)
> GCC's builtin headers should not be in your heater search path at all. Are
> you explicitly specifying them, or is clang's driver erroneously adding them
> for you?

They are in the builtin include search path:

$ clang -v -c tdirent.c
clang version 3.7.1 (tags/RELEASE_371/final)
Target: i686-pc-windows-cygnus
Thread model: posix
 "/usr/bin/clang-3.7" -cc1 -triple i686-pc-windows-cygnus -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name tdirent.c -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -target-cpu pentium4 -v -dwarf-column-info -coverage-file /home/HBB/tmp/tdirent.c -resource-dir /usr/bin/../lib/clang/3.7.1 -fdebug-compilation-dir /home/HBB/tmp -ferror-limit 19 -fmessage-length 149 -mstackrealign -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -o tdirent.o -x c tdirent.c
clang -cc1 version 3.7.1 based upon LLVM 3.7.1 default target i686-pc-windows-
cygnus
ignoring nonexistent directory "/usr/local/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/bin/../lib/clang/3.7.1/include
 /usr/lib/gcc/i686-pc-cygwin/5.3.0/include
 /usr/include
 /usr/include/w32api
End of search list.