Re: [bug-gnulib] Re: stdint vs cycle-check.h

[Bruno Haible]

Mark D. Baushke wrote:
> Paul Eggert <eggert@CS.UCLA.EDU> writes:
> 
> > "Mark D. Baushke" <mdb@gnu.org> writes:
> >
> > > is it desirable to make those modules depend on stdint.m4 and avoid the
> > > HAVE_STDINT_H macro?
> >
> > Yes, I think so, in the long run.  But in the short run, stdint.m4 is
> > not yet reliable enough (as you're finding out with SGI), and some
> > packages don't want to rely on it for that reason.
> >
> > For cycle-check.h I'd think this wouldn't be a problem, since
> > cycle-check.h uses this Autoconf-recommended sequence:
> >
> > # if HAVE_INTTYPES_H
> > #  include <inttypes.h>
> > # endif
> > # if HAVE_STDINT_H
> > #  include <stdint.h>
> > # endif
> >
> > and this should work on SGI.
> 
> With lots and lots of warnings, yes.
> 
> The HAVE_STDINT_H is defined, even though it is useless

You are welcome to submit patches for ptrdiff_max.m4 and size_max.m4 and
xsize.m4 so that they don't define HAVE_STDINT_H.

> In CVS, the windows-NT does not supply a <stdint.h>, so we use stdint.m4
> to create one. However, the lib/*.c files do not build because there is
> not one available when we tell the truth about HAVE_STDINT_H being
> undef

Several gnulib modules still use the classical

  #ifdef HAVE_STDINT_H
  # include <stdint.h>
  #endif

pattern. Now we are testing the stdint complete module, 'libiconv' and
'cvs' being the guinea pigs. In a few months, we will get used to
using <stdint.h> unconditionally like we now use <stdbool.h> without much
thinking, and the various variants (ptrdiff_max.m4, size_max.m4, intmax_t.m4,
uintmax_t) may disappear.

Bruno