bug-gnulib
[Top][All Lists]
Advanced

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

Re: [Bug-gnulib] Re: gnulib module for uintmax_t? (and best practice que


From: Paul Eggert
Subject: Re: [Bug-gnulib] Re: gnulib module for uintmax_t? (and best practice questions)
Date: Mon, 25 Oct 2004 14:38:30 -0700
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

Simon Josefsson <address@hidden> writes:

> However, this wouldn't solve the problem with using uint32_t in
> installed header files.

Don't you already have this problem?  If the compilation of the
installed header file depends on config.h in any way, you need to make
sure that applications that use the API have a config.h that is
compatible with the config.h used to generate the library.  This
is a difficult problem in general.

For example, suppose you use GCC to generate the library, and it
supplies a <stdint.h>, but the library user compiles with some other
compiler that lacks <stdint.h>.  If the library's include files
include <stdint.h> then these users will have problems (in effect,
their config.h files will be incompatible with the library's).


> POSIX require uint32_t though, and most sane systems have it, which is
> enough for me for now.

OK, fair enough.  I didn't know that fact about POSIX, by the way;
thanks for mentioning it.  (Though I note that uint64_t is not
required by POSIX, even though uint_least64_t is required.  Weird.)


> Perhaps I should use wchar, but it seem less portable (wchar not
> required to hold full Unicode), and nobody has asked for it, and
> most importantly, I don't understand it.

OK, but if your application is Unicode code points then why not do
what linebreak and unicodeio do?  They just use "unsigned int".  This
avoids all the above programs.

"unsigned int" is not portable in theory, since unsigned int is not
necessarily 32 bits.  But it's quite portable in practice -- note that
the GNU coding standards say that you can assume that int is at least
32 bits wide.  If your code still works correctly even if unsigned int
is wider than 32 bits then that may be enough for you, just as it is
enough for linebreak and unicodeio.

If you want to support weird modern hosts where unsigned int is not 32
bits, and if your code assumes that the type is exactly 32 bits wide
or you are worried about efficient storage, then I suppose you could
do something like this:

#include <limits.h>
#if HAVE_STDINT_H
# include <stdint.h>
#endif

#ifndef UINT32_MAX
# if UINT_MAX == 4294967295
#  define UINT32_MAX UINT_MAX
#  define uint32_t unsigned int
# else
#  error "cannot find 32-bit unsigned integer type"
# endif
#endif

and then use uint32_t instead of unsigned int.  linebreak and
unicodeio didn't do that, though, and this indicates that you needn't
bother either.




reply via email to

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