bug-gnulib
[Top][All Lists]
Advanced

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

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


From: Simon Josefsson
Subject: [Bug-gnulib] Re: gnulib module for uintmax_t? (and best practice questions)
Date: Tue, 26 Oct 2004 00:09:37 +0200
User-agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux)

Paul Eggert <address@hidden> writes:

> 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.

Right.  But my installed headers do #include idn-int.h, which is the
generated file from the M4 macro I posted.  It doesn't need config.h
(although the generated idn-int.h might make you think that, since it
contain lots of #ifdef HAVE_FOO).

> 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).

Yes.  That's why I ship the separate file, idn-int.h, that define
uint32_t the way I want it to be defined.  I.e., unsigned integer that
is 32-bit wide ABI/API-wise.

Perhaps it is possible that another compiler on the same host would
parse idn-int.h differently than GCC does, though.  Hm.

>> 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.

I used to do this.  But people complained that on 64-bit platforms,
'unsigned int' is not the same width as uint32_t, and people had their
Unicode data on uint32_t format.  Converting from 64 bit integers to
32 bit integers is painful.  Since 32-bit platforms would be
practically unaffected, API/ABI-wise, I made the change.

I feared that when I made the change, people would then complain that
they store Unicode code points in 'unsigned int' in their package, and
that the library isn't compatible with that.  But nobody has said
anything, and I made the change long time ago.

> 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.

The uint32_t is needed in the headers, so the above fragment wouldn't
work directly, since config.h can't be assumed.

But for what its worth, in GSS I use the following.  Perhaps it is
possible to define a uint32_t in a portable way, without config.h, in
this approach.

/*
 * The following type must be defined as the smallest natural
 * unsigned integer supported by the platform that has at least
 * 32 bits of precision.
 */
#include <limits.h>
#if USHRT_MAX >= 4294967295
typedef unsigned short gss_uint32;
#elif UINT_MAX >= 4294967295
typedef unsigned int gss_uint32;
#else /* unsigned long's must be at least 32 bits according to K&R */
typedef unsigned long gss_uint32;
#endif

Thanks.





reply via email to

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