solaris2 float.h/limits.h conflict

[Jim Wilson <wilson at cygnus dot com>]

On Solaris2, limits.h defines some macros that are supposed to be defined
in float.h.  If you include float.h and then limits.h, you get macro
redefinition warnings which are an annoyance.  If you use -pedantic-errors,
then you get errors even though the user program has no errors.

ryobi<61>cat tmp.c
#include <float.h>
#include <limits.h>
main(){}
ryobi<62>./xgcc -B./ tmp.c
In file included from include/syslimits.h:7,
                 from include/limits.h:11,
                 from tmp.c:2:
/usr/include/limits.h:163: warning: `DBL_MAX' redefined
include/float.h:63: warning: this is the location of the previous definition
/usr/include/limits.h:165: warning: `DBL_MIN' redefined
include/float.h:54: warning: this is the location of the previous definition
/usr/include/limits.h:168: warning: `FLT_MAX' redefined
include/float.h:35: warning: this is the location of the previous definition
/usr/include/limits.h:169: warning: `FLT_MIN' redefined
include/float.h:26: warning: this is the location of the previous definition

The normal way of handling this is to copy limits.h, and insert #ifndef
before the problematic #defines.  Solaris however uses fixinc.wrap which
has the philosophy that we should never copy a system header file to avoid
OS revision problems.  Instead, we use #include_next, and add workarounds
before or after the include_next.

Unfortunately, I can't see any good way to solve the problem by using
fixinc.wrap methods.  We can't just undefine DBL_MAX before the include_next,
because DBL_MAX is conditionally defined.  If we copy the conditions, then
we are open to OS revision problems if the conditions change.  There is no
way to store the value of DBL_MAX in a temporary by using preprocessor
commands, so we can't save and restore the value.

The only solution I've seen so far is to modify gcc's float.h to avoid the
conflict.  float.h has
	#define DBL_MAX 1.7976931348623157e+308
and limits.h has
	#define	DBL_MAX		1.7976931348623157E+308
so we can make the problem go away by changing the 'e' in float.h to an 'E'.
solaris2 is the only target that uses float-i128.h, so we wouldn't even affect
any other target if we made this change.

It seems a bit unseemly to fix the problem this way though, so I am looking
for any other suggestions, or whether anyone has objections to this change.

Jim