Re: OpenBSD does not define INT8_MIN etc.

[Marius Vollmer <mvo@zagadka.de>]

Andreas Vögele <voegelas@gmx.net> 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


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel