Re: __LONG_MAX__

[Michael Meissner <meissner at cygnus dot com>]

On Wed, Sep 02, 1998 at 04:00:09PM -0400, Gavin Romig-Koch wrote:
> 
> In the mips tool chain there is a fairly hairy set of options which
> decide whether long's are 4 or 8 bytes wide.  Getting the specs correct
> for __LONG_MAX__ is an on-going difficulty.
> 
> I'm wondering if we could just make the definition of 
> __LONG_MAX__ in glimits.h depend directly on the size of 
> unsigned longs, as in the patch below, and so remove the need
> for any complicated handling of __LONG_MAX__ in the specs (for
> most cases).  
> 
> This only works for 2's compliment machines; other kinds of hardware
> would require other special handling (does gcc support non- 2's
> compliment?).  Otherwise, I think this works and is ISO conforming.
> Does any one see a problem with it?  Is it ok to commit?

Yes, it should not be checked in.  Otherwise, uses cannot code the following
legal ISO C program:

     #include <limits.h>

     int main()
     {
     #if LONG_MAX > 2147483647L
	 printf ("longs are 4 bytes\n");
     #else
	 printf ("longs are not 4 bytes\n");
     #endif
	return 0;
     }

This is because sizeof (even of fundamental types) is not available to the
preprocessor.

-- 
Michael Meissner, Cygnus Solutions (Massachusetts office)
4th floor, 955 Massachusetts Avenue, Cambridge, MA 02139, USA
meissner@cygnus.com,	617-354-5416 (office),	617-354-7161 (fax)