clang copy of limits.h misses NAME_MAX

Hans-Bernhard Bröker HBBroeker@t-online.de
Thu Mar 17 14:02:00 GMT 2016


Am 17.03.2016 um 14:42 schrieb Ismail Donmez:
> On Thu, Mar 17, 2016 at 3:35 PM, Marco Atzeri <marco.atzeri@gmail.com> wrote:
>> it seems to prefer gcc headers
>>
>> # 1 "/usr/bin/../lib/clang/3.7.1/include/limits.h" 1 3 4
>> # 37 "/usr/bin/../lib/clang/3.7.1/include/limits.h" 3 4
>> # 1 "/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/limits.h" 1 3 4
>> # 38 "/usr/bin/../lib/clang/3.7.1/include/limits.h" 2 3 4
>> # 17 "/usr/include/sys/dirent.h" 2 3 4
>
> I am looking at clang 3.7 headers on Linux so this might be not 100%
> same on Cygwin but, clang's limits.h has this on top:
>
> /* 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
>
> which should prevent including gcc's own limits.h but looks like it doesn't.

Actually, that would only try to prevent expanding the contents of GCC's 
limits.h, by pre-setting its multiple-inclusion guard macro.  Which 
means that the

	#include_next<limits.h>

following it now begins to look at GCC's version, bounces off the guard 
macro, and finishes.  The actual system <limits.h> would have been 
#include_next'ed in turn (line 168 of /usr/lib/gcc/.../limits.h), but 
that was disabled by the above hack.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple



More information about the Cygwin mailing list