Re: uintmax_t

[Paul Eggert]

> From: Akim Demaille <address@hidden>
> Date: 05 Oct 2001 19:42:33 +0200
> 
> I'm especially interested in your checking the *order* in which the
> headers are being tested: who is more std than the other?  stdint or
> inttypes?

inttypes.h works on more hosted implementations that stdint.h does, so
it's more "standard" in that sense.  stdint.h is a relatively recent
header -- it was introduced by the C99 committee during the
standardization process.  By design, inttypes.h includes stdint.h, so
as far as the standard is concerned, the only reason that one would
ever want to include stdint.h is when inttypes.h does not exist.
C99 allows "freestanding" implementations to omit inttypes.h.

I don't think there will ever be any hosts where it helps to include
both inttypes.h and stdint.h.  I think it a tad more likely that we'll
run into buggy hosts where it hurts to include both headers -- in fact
I vaguely recall running into one, but unfortunately I don't remember
what it was.  Also, it's a bit confusing to suggest to people to
include both headers, when the standard says that one includes the
other.  So I suggest using this pattern uniformly, in both code and
documentation:

     #if HAVE_INTTYPES_H
     # include <inttypes.h>
     #else
     # if HAVE_STDINT_H
     #  include <stdint.h>
     # endif
     #endif

> if unsigned long long is present but not very satisfying, how could
> it be worse than unsigned long?

On some compilers, unsigned long long doesn't work in general, even
though the keyword combination "unsigned long long" is accepted and
some very simple code does work.  jm_AC_TYPE_LONG_LONG and
jm_AC_TYPE_UNSIGNED_LONG_LONG tests for the troublesome cases that we
know about.  Fortunately, the bad compilers that we know about can all
be caught by link time.

If AC_CHECK_TYPES([long long, unsigned long long]) would do those
tests for us, we wouldn't need jm_AC_TYPE_LONG_LONG and
jm_AC_TYPE_UNSIGNED_LONG_LONG.

> --- doc/autoconf.texi Fri, 05 Oct 2001 16:26:43 +0200 akim
> +++ doc/autoconf.texi Fri, 05 Oct 2001 19:21:05 +0200 akim
> @@ -2988,10 +2988,9 @@ @node Default Includes
>  #endif
>  #if HAVE_INTTYPES_H
>  # include <inttypes.h>
> -#else
> -# if HAVE_STDINT_H
> +#endif
> +#if HAVE_STDINT_H
>  #  include <stdint.h>
> -# endif
>  #endif

I prefer it the old way, for the reasons suggested above.

I would rewrite the major part of the documentation change as follows.
The basic idea here (aside from the quibble with including both files)
is to move the long-long gorp into configure.ac, with the goal of
eventually moving it into autoconf itself.  This keeps system.h
simpler.  That is how fileutils, tar, etc. do things.

---

@cindex @code{uintmax_t}
The modern uses of @code{AC_CHECK_TYPES} work like
@code{AC_CHECK_FUNCS}, not like @code{AC_REPLACE_FUNCS}.
Let's take @code{intmax_t} as an example.

The type @code{intmax_t} is defined by either @file{inttypes.h} or
@file{stdint.h}.  The C Standard says that @file{inttypes.h} includes
@file{stdint.h} and that there's no reason to include both files, but
some systems lack one header or the other, and on some buggy systems
the headers cannot both be included.  Both headers are part of the
default includes (@xref{Default Includes}), and are checked for
presence and compatibility by @code{AC_CHECK_HEADERS}.  Therefore, no
explicit check for headers is needed, and the following
@file{configure.ac} snippet can be used:

@example
AC_CHECK_TYPES([intmax_t], ,
  [AC_CHECK_TYPES([long long],
     [AC_DEFINE(intmax_t, long long,
        [Define to widest signed type if <inttypes.h> doesn't define.])],
     [AC_DEFINE(intmax_t, long,
        [Define to widest signed type if <inttypes.h> doesn't define.])])])
@end example

@noindent
and @file{system.h} should contain:

@example
#if HAVE_INTTYPES_H
# include <inttypes.h>
#else
# if HAVE_STDINT_H
#  include <stdint.h>
# endif
#endif
@end example