[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.
- Re: [Cvs-dev] Re: [Cvs-test-results] Build CVS (TRUNK) failed., Derek R. Price, 2006/06/11
- Re: [Cvs-dev] Re: [Cvs-test-results] Build CVS (TRUNK) failed., Paul Eggert, 2006/06/12
- Re: [Cvs-dev] Re: [Cvs-test-results] Build CVS (TRUNK) failed., Mark D. Baushke, 2006/06/12
- stdint module rewrite (was: Re: Build CVS (TRUNK) failed.), Bruno Haible, 2006/06/13
- Re: stdint module rewrite, Simon Josefsson, 2006/06/13
- Re: stdint module rewrite, Bruno Haible, 2006/06/13
- Re: stdint module rewrite, Simon Josefsson, 2006/06/14
- Re: stdint module rewrite, Bruno Haible, 2006/06/16
- Re: stdint module rewrite,
Paul Eggert <=
- Re: stdint module rewrite, Bruno Haible, 2006/06/13
- Re: stdint module rewrite, Paul Eggert, 2006/06/13
- Re: stdint module rewrite, Bruno Haible, 2006/06/13
- Re: stdint module rewrite (was: Re: Build CVS (TRUNK) failed.), Ralf Wildenhues, 2006/06/13
- Re: stdint module rewrite (was: Re: Build CVS (TRUNK) failed.), Bruno Haible, 2006/06/13
- Re: stdint module rewrite (was: Re: Build CVS (TRUNK) failed.), Ralf Wildenhues, 2006/06/14
- Re: stdint module rewrite (was: Re: Build CVS (TRUNK) failed.), Bruno Haible, 2006/06/16
- Re: stdint module rewrite, Ralf Wildenhues, 2006/06/16
- Re: stdint module rewrite (was: Re: Build CVS (TRUNK) failed.), Mark D. Baushke, 2006/06/13
- Re: stdint module rewrite (was: Re: Build CVS (TRUNK) failed.), Bruno Haible, 2006/06/16