[llvm-bugs] [Bug 27001] New: include_next of limits.h still broken

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=27001

            Bug ID: 27001
           Summary: include_next of limits.h still broken
           Product: clang
           Version: 3.7
          Hardware: PC
                OS: Windows XP
            Status: NEW
          Severity: normal
          Priority: P
         Component: Headers
          Assignee: unassignedclangbugs at nondot.org
          Reporter: HBBroeker at T-Online.de
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160319/5e2d45e4/attachment.html>