[Top][All Lists]
[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:20:21 +0200 |
User-agent: |
Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) |
Bruno Haible <address@hidden> writes:
> Simon Josefsson wrote:
>> This doesn't work with installed header files, does it?
>
> Ad 1) How to install header files which define uint32_t?
>
> I recommend to just not do it. The reason is that only one typedef for
> uint32_t is possible in a compilation unit. On a platform that does not
> define uint32_t by itself, it's likely that many packages will define it.
> Some will define it differently. What happens then? You can avoid the
> compilation errors by using #define instead of typedef, but this still
> doesn't resolve the problem.
>
> In the similar case with errno values (good comparison, Paul!) I once had
> the case, on a platform lacking EILSEQ (BSD/OS I think), one piece of
> software did #define EILSEQ EINVAL
> and another did #define EILSEQ ENOENT.
> The program crashed, of course, because it didn't interpret the errno
> values correctly. Similar things will happen if one piece of code
> defines intmax_t as being a 32-bit type, and for another compilation unit
> it's a 64-bit type.
>
> The workaround, ugly as it is, is to define library specific types,
> such as idn_uint32_t. GNU gettext has been using
> typedef unsigned int nls_uint32_t;
> for years without problems.
I understand your argument, but the workaround has so pervasive
consequences that I want to try to find a better compromise.
Having to replace all occurrences of uint32_t with @address@hidden
in every package not only produce hard to read source code, but also
interesting type casting problems: is it OK to cast idn_uint32_t to
nls_uint32_t? To see where it may be confusing, compare gss_uint32_t
(see source code comment in other post) which is not really equivalent
to the real uint32_t. Yes, the confusing definition of gss_uint32_t
is evil, but the API is from an RFC and isn't likely to change due to
interoperability concerns. This might not be a strong argument, but
it is enough for me to doubt that workaround.
> I would propose to let the autoconf macro determine the full pathname of
> the system's <stdint.h> (through "$CC -E" and grepping for #line statements),
> and do a #include of this full pathname at the beginning of our stdint.h.
What if the system has several compilers, each with its own stdint.h?
I realize the M4 macro I posted probably doesn't handle this either,
but if we are thinking about a proper solution, let's do that.
Thanks.
- [Bug-gnulib] Re: gnulib module for uintmax_t? (and best practice questions), (continued)
- [Bug-gnulib] Re: gnulib module for uintmax_t? (and best practice questions), Simon Josefsson, 2004/10/25
- [Bug-gnulib] Re: gnulib module for uintmax_t? (and best practice questions), Paul Eggert, 2004/10/25
- [Bug-gnulib] Re: gnulib module for uintmax_t? (and best practice questions), Simon Josefsson, 2004/10/25
- Re: [Bug-gnulib] Re: gnulib module for uintmax_t? (and best practice questions), Paul Eggert, 2004/10/25
- [Bug-gnulib] Re: gnulib module for uintmax_t? (and best practice questions), Simon Josefsson, 2004/10/25
- Re: [Bug-gnulib] Re: gnulib module for uintmax_t? (and best practice questions), Paul Eggert, 2004/10/25
- [Bug-gnulib] Re: gnulib module for uintmax_t? (and best practice questions), Simon Josefsson, 2004/10/26
- Re: [Bug-gnulib] Re: gnulib module for uintmax_t? (and best practice questions), Bruno Haible, 2004/10/25
- [Bug-gnulib] Re: gnulib module for uintmax_t? (and best practice questions), Simon Josefsson, 2004/10/25
- Re: [Bug-gnulib] Re: gnulib module for uintmax_t? (and best practice questions), Bruno Haible, 2004/10/25
- [Bug-gnulib] Re: gnulib module for uintmax_t? (and best practice questions),
Simon Josefsson <=
- Re: [Bug-gnulib] Re: gnulib module for uintmax_t? (and best practice questions), Bruno Haible, 2004/10/26