jeff@cs.warwick.ac.uk (Jeff Smith) (06/08/89)
The situation in which LONG_MIN is the negative of a
positive number whose magnitude is greater than LONG_MAX
in <limits.h> has prompted me to think about the
way in which the <limits.h> file is derived.
It be useful to envelope <limits.h> in
#ifdef __GNUC__
....
#endif /* __GNUC__ */.
A better way of dealing with <limits.h> would be to get the compiler
to write out the values directly, as part of the installation process,
and combine them with any existing <limits.h> thus
#if defined(__GNUC__) && defined(targetarch)
... limits produced from cc1
#else /* ! ((defined(__GNUC__) && defined(targetarch)) */
.. any existing limits
#endif /* defined(__GNUC__) && defined(targetarch) */
This is an important issue in environments supporting cross-compilation
or multiple C compilers.
Perhaps the compiler should take its values from a limits.h
rather than deducing them from the number of bits per word? This
would be less dependent on the hardware representation and would
save the changes necessary to make the compiler write the values
out itself, or the construction of a program to deduce them and write
them out.
Cross-compilation issues, the redefinition of limits and the
changes necessary to propagate the limit.h symbols through
to cc1 imply that resolving the limit symbols directly in the
compiler proper is not practical.
Jeff Smith
jeff@cs.warwick.ac.uk
mcvax!warwick!jeff