[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: stdint module rewrite

From: Paul Eggert
Subject: Re: stdint module rewrite
Date: Tue, 13 Jun 2006 11:16:23 -0700
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)

Bruno Haible <address@hidden> writes:

> Here is a proposed rewrite of the stdint module. It defines a
> *complete* <stdint.h>, and is autoconfiguring - no more
> #ifdef __FreeBSD__ etc. that are hard to maintain.
> It appears to work fine on Solaris and HP-UX IA64.
> The only downside is that it bloats up 'configure' - but autoconf 3
> should annihilate that growth, I'm told.

Autoconf 3 won't be out for quite some time, I'm afraid.

The approach assumes a conventional architecture in which there are
underyling signed and unsigned types of width 8, 16, 32, and 64, and
the only argument is which int*_t type is which.  That's likely the
only case worth worrying about, for backward compatibility reasons
anyway.  How about simplifying things as follows?

1.  If the system <stdint.h> doesn't work, we omit it entirely,
    and substitute our own entirely.

2.  We work around incompatibilities between our substitute
    and the standard header files by having our stdint.h substitute
    do this first:

    #define int_fast32_t rpl_int_fast32_t
    #define int_fast64_t rpl_int_fast64_t
    [include <sys/inttypes.h>, FULL_PATH_INTTYPES_H, etc., here]
    #undef int_fast32_t
    #undef int_fast64_t
    #undef INT_FAST32_MIN
    #undef INT_FAST32_MAX
    #undef INT_FAST64_MIN
    #undef INT_FAST64_MAX

An advantage of this approach is that we will work around subtle bugs
in existing implementations, if ours is good.  For example, on Solaris
10, UINT16_MAX is (65535U) which is incorrect; it's supposed to be a
signed value.  (Both the current and the proposed stdint.h have the
same bug, but we can fix it.  :-)

Another advantage is that it won't require many Autoconf tests;
basically, whether 'long' is 32 or 64 bits, and whether 'long long' is
available (we can assume it's 64 bits, I suppose).

A disadvantage of this approach is that if our opinion of int_fast32_t
disagrees with that of the (broken) system file, and if some other
system header uses int_fast32_t, then we could be hosed.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]