Re: AC_TYPE_UINT32_T and AC_TYPE_UINTMAX_T nits

[Ralf Wildenhues]

Hello Bruno,

* Bruno Haible wrote on Sat, Jun 17, 2006 at 07:26:39PM CEST:
> 
> 1) When the types exist:
> 
> checking for uint8_t... uint8_t
> checking for uint16_t... uint16_t
> checking for uint32_t... uint32_t
> checking for unsigned long long int... yes
> checking for uintmax_t... yes
> checking for uintptr_t... yes
> 
> Suggestion: change the first three lines to
> 
> checking for uint8_t... yes
> checking for uint16_t... yes
> checking for uint32_t... yes
> 
> It'd be more consistent with the printout of other autoconf tests.

I may be talked into changing this; it deals with new macros only, and
changing this later, with released versions of these macros already
spread around the globe, we run into a slight cache variable backwards
incompatibility; and the patch is pretty simple, see below.  (The patch
overlaps with your bug report, so you might see spurious conflicts there
unless you apply the other patch first.)  Please test it.

> 2) And when the types do not exist, such as on Solaris 2.5.1, the output is:
> 

> checking for uintmax_t... no
> checking for uintptr_t... no
> 
> Since the macros arrange for uintmax_t and uintptr_t to be present, it
> would be more consistent to change the last two lines to include the
> value that is put into config.h, namely:
> 
> checking for uintmax_t... unsigned long long int
> checking for uintptr_t... unsigned int

Yes, it would be.  But that would require a larger modification than I'm
currently willing to put into Autoconf.  Basically, it would be nice if
the replacement type could be cached, rather than the fact whether the
type is present or not.  But then we shouldn't use AC_CHECK_TYPE in
AC_TYPE_*INTPTR_T and AC_TYPE_*INTMAX_T.

IMVHO this is not a critical bug; all information the package maintainer
seeks can be deduced from config.log output, and the nicer configure
output can be fixed sometime later.  (Surely the other comments about
the first case apply here as well; oh well...)

Any disagreements over this?  OK to apply the patch below?

Cheers,
Ralf

        * lib/autoconf/types.m4 (_AC_TYPE_INT): Set `$ac_cv_c_int$1_t'
        to `yes' instead of `int$1_t' if the type is found, for more
        consistent configure output (where $1 is the number of bits).
        (_AC_TYPE_UINT): Likewise for `uint$1_t'.
        Suggested by Bruno Haible.

Index: lib/autoconf/types.m4
===================================================================
RCS file: /cvsroot/autoconf/autoconf/lib/autoconf/types.m4,v
retrieving revision 1.37
diff -u -r1.37 types.m4
--- lib/autoconf/types.m4       8 Apr 2006 21:46:04 -0000       1.37
+++ lib/autoconf/types.m4       18 Jun 2006 08:59:19 -0000
@@ -590,11 +590,13 @@
               [[($ac_type) (((($ac_type) 1 << ($1 - 2)) - 1) * 2 + 1)
                 < ($ac_type) (((($ac_type) 1 << ($1 - 2)) - 1) * 2 + 2)]])],
            [],
-           [ac_cv_c_int$1_t=$ac_type])])
+           [AS_CASE([$ac_type], [int$1_t],
+              [ac_cv_c_int$1_t=yes],
+              [ac_cv_c_int$1_t=$ac_type])])])
        test "$ac_cv_c_int$1_t" != no && break
      done])
   case $ac_cv_c_int$1_t in #(
-  no|int$1_t) ;; #(
+  no|yes) ;; #(
   *)
     AC_DEFINE_UNQUOTED([int$1_t], [$ac_cv_c_int$1_t],
       [Define to the type of a signed integer type of width exactly $1 bits
@@ -614,13 +616,15 @@
         [AC_LANG_BOOL_COMPILE_TRY(
            [AC_INCLUDES_DEFAULT],
            [[($ac_type) -1 >> ($1 - 1) == 1]])],
-        [ac_cv_c_uint$1_t=$ac_type])
+        [AS_CASE([$ac_type], [uint$1_t],
+           [ac_cv_c_uint$1_t=yes],
+           [ac_cv_c_uint$1_t=$ac_type])])
        test "$ac_cv_c_uint$1_t" != no && break
      done])
   case $ac_cv_c_uint$1_t in #(
-  no|uint$1_t) ;; #(
+  no|yes) ;; #(
   *)
     m4_bmatch([$1], [^\(8\|32\|64\)$],
       [AC_DEFINE([_UINT$1_T], 1,
         [Define for Solaris 2.5.1 so the uint$1_t typedef from
          <sys/synch.h>, <pthread.h>, or <semaphore.h> is not used.