redefined symbols issue

[Iain Hibbert <plunky%ogmig.net@localhost>]

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