Hello I found an issue when compiling NetBSD sources with pcc, which I am not sure where the 'fault' lies, as pcc handles this slightly differently than gcc (and clang) though the cause of it seems strange in its own right.
The problem I face is that DBL_DIG, DBL_MAX, DBL_MIN, FLT_DIG, FLT_MAX and FLT_MIN are defined in <machine/limits.h> and <sys/float_ieee754.h> both, and during a build of (eg) libc/absvdi2.o, I get an error because they are defined slightly differently. For example, in <i386/limits.h> I see: #define DBL_DIG 15 whereas in <sys/float_ieee754.h> there is effectively: #define DBL_DIG __DBL_DIG__ which does evaluate to the same thing in the end, but is different in the context of the preprocessor. Now, the reason that gcc has not complained about this, is that warnings about redefinitions inside a system header are supressed (and note that pcc also does this). BUT, crucially, the float_ieee754.h file that is included by the compilation is not really a system header because we provided -I $SRC/sys on the commandline.. meaning that the included files were: % cat test.c #include <float.h> % gcc -E -I /usr/src/sys test.c # 1 "test.c" # 1 "<command-line>" # 1 "test.c" # 1 "/usr/include/float.h" 1 3 4 # 1 "/usr/include/x86/float.h" 1 3 4 # 1 "/usr/src/sys/sys/featuretest.h" 1 3 4 # 7 "/usr/include/x86/float.h" 2 3 4 # 18 "/usr/include/x86/float.h" 3 4 # 1 "/usr/src/sys/sys/float_ieee754.h" 1 3 4 [...] and so you can see (from the "3" flag), that although the float_ieee754.h file is not in the system include path, because it was included from within a system header then gcc does still consider it a system header. This behaviour is not enumerated in the cpp.info file (there is a System Headers page) and pcc does not currently behave that way. (I am not sure if clang has a document describing its behaviour wrt this, I could not find one) So, there are a bunch of questions thrown up by this 1. should we be mixing /usr/include and $SRC headers in this way? - this does not feel right to me 2. do we really need to define such symbols in more than one place? - it also does not feel right to me 3. should the definitions be different? - the HPPA limits.h file makes an effort to use compiler provided constants when possible 4. do these definitions actually need to be in the machine/limits.h file? - the kernel does not use them anyway 5. does pcc need to be changed? - I can just change pcc to behave like gcc in this regard, which makes this issue go away thoughts? iain