bug-gnulib
[Top][All Lists]
Advanced

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

Re: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on S


From: Niels Möller
Subject: Re: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc
Date: Mon, 07 May 2012 19:13:02 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (usg-unix-v)

Paul Eggert <address@hidden> writes:

> Hmm, well, the latter point is dubious.  SunOS 5.10 standard headers do not
> mention int_fast*_t, except in stdint.h where C requires their definition.

I'd consider that definition to be authoritative...

> Presumably this is for the same reason that Gnulib avoids these types.
> Arguably these types are not part of the SunOS 5.10 ABI, since nothing
> in the SunOS library binary interface use them.

C is still the system programming language, and int_fast*_t are part of
the language. But maybe we're splitting hairs now.

> The main reason is to keep gnulib simple and maintainable.
> I'd rather not have to hand-maintain details about an
> operating system that hasn't shipped since 2009.

I thought the point of gnulib was to do those annoying things to keep
the maintanance in one place. But I guess I'll have to leave to the
judgment of the gnulib maintainers which systems are too old and
obsolete to care about.

> How does the nettle stuff work?  Does it #define int_fast8_t etc
> in config.h?

It is defined in a generated file nettle-stdint.h. And the names of the
types are all typedefs, no #defines.

With AX_CREATE_STDINT_H, it's a file generated independently of
config.h. The file starts with a section with a bunch of #defines set up
by configure, and then the rest of the file uses various tests on these
to decide what file to include and which types to define. Where the
common case is to just include the system's <stdint.h>. The file is then
installed with the other nettle header files.

> If so, there's a simple workaround in gnulib:
> don't futz with int_fast8_t if it's already #defined.

If one could get that to work, it might solve the problem for the case
that the types are defined but not used. But if it implies that size of
those types will depend on #include order, it seems very brittle to me.
I think it would be better to let the gnulib application say explicitly
whether or not it needs those types, and not define them at all in the
common case that they aren't needed. I.e.,

#ifdef GL_WANT_INTX_FAST_T
# define int_fast8_t gl_int_fast8_t
#endif

Not sure where one would define GL_WANT_INTX_FAST_T, if desired, though.
Should be specified in some way in configure.ac, but it can't be put in
config.h if the stdint.h types are needed for installed header files.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.



reply via email to

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