<html>
<head>
<base href="https://llvm.org/bugs/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - include_next of limits.h still broken"
href="https://llvm.org/bugs/show_bug.cgi?id=27001">27001</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>include_next of limits.h still broken
</td>
</tr>
<tr>
<th>Product</th>
<td>clang
</td>
</tr>
<tr>
<th>Version</th>
<td>3.7
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Windows XP
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>Headers
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedclangbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>HBBroeker@T-Online.de
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>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 <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - limits.h "#include_next madness" misses include system limits.h"
href="show_bug.cgi?id=6379">Bug 6379</a>, 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".</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>