This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
__LONG_MAX__
- To: egcs at cygnus dot com, egcs-patches at cygnus dot com
- Subject: __LONG_MAX__
- From: Gavin Romig-Koch <gavin at cygnus dot com>
- Date: Wed, 2 Sep 1998 16:00:09 -0400 (EDT)
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?
-gavin...
* glimits.h (__LONG_MAX__) : Change definition to depend
directly on the size of longs.
Index: gcc/glimits.h
===================================================================
***************
*** 64,74 ****
/* Minimum and maximum values a `signed long int' can hold.
(Same as `int'). */
#ifndef __LONG_MAX__
! #if defined (__alpha__) || (defined (__sparc_v9__) && defined (__arch64__))
! #define __LONG_MAX__ 9223372036854775807L
! #else
! #define __LONG_MAX__ 2147483647L
! #endif /* __alpha__ || sparc64 */
#endif
#undef LONG_MIN
#define LONG_MIN (-LONG_MAX-1)
--- 64,70 ----
/* Minimum and maximum values a `signed long int' can hold.
(Same as `int'). */
#ifndef __LONG_MAX__
! #define __LONG_MAX__ (((unsigned long)-1)/2)
#endif
#undef LONG_MIN
#define LONG_MIN (-LONG_MAX-1)