[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: OpenBSD does not define INT8_MIN etc.
From: |
Marius Vollmer |
Subject: |
Re: OpenBSD does not define INT8_MIN etc. |
Date: |
Sat, 10 Jul 2004 15:26:41 +0200 |
User-agent: |
Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) |
Andreas Vögele <address@hidden> writes:
> OpenBSD 3.5 doesn't define INT8_MIN, INT8_MAX, UINT8_MAX etc.
Damn. I knew we couldn't rely on these being available...
> I could write a patch for gen-scmconfig.c and/or configure.in that
> handles this problem but I'm wondering why INT8_MIN etc. are
> necessary at all. Are there any architectures where INT8_MIN,
> INT16_MIN etc. aren't -128, -32768 etc.?
Yep, I had the same thoughts. There's no problem with INT8_MIN etc,
but I was afraid that for the larger sizes, there would be no portable
way to write the constants. For example, with GCC, UINT64_MAX is
"18446744073709551615ULL" where the "ULL" suffix is essential. That's
why I wanted to use the platform definition of UINT64_MAX, and for
symmetry, I used the platform definitions for the rest as well.
However, we already need to define LLONG_MIN, etc ourselves, and
currently, we rely on integers being in twos-complement. So, we could
just as well forego the platform definitons of INT8_MIN etc and define
them ourselves, maybe like so:
#define SCM_I_UTYPE_MAX(type) (~(type)0)
#define SCM_I_TYPE_MAX(type,utype) ((type)((~(utype)0)/2))
#define SCM_I_TYPE_MIN(type,utype) (-((type)((~(utype)0)/2))-1)
#define SCM_T_UINT8_MAX SCM_I_UTYPE_MAX(scm_t_uint8)
#define SCM_T_INT8_MIN SCM_I_TYPE_MIN(scm_t_int8,scm_t_uint8)
#define SCM_T_INT8_MAX SCM_I_TYPE_MAX(scm_t_int8,scm_t_uint8)
...
That should work for all kind of types.
I'll make this change.
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405