[Top][All Lists]

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

Re: AC_TYPE_UINT8_T and co

From: Patrick Welche
Subject: Re: AC_TYPE_UINT8_T and co
Date: Wed, 30 May 2007 11:48:42 +0100
User-agent: Mutt/1.5.14 (2007-03-22)

On Wed, May 30, 2007 at 11:31:56AM +0200, Stepan Kasal wrote:
> I'm afraid there are some misunderstandings here.  I'll try to
> make things more clear.
> Let's start with your very first mail:
> Until yesterday, the manual said:
> | -- Macro: AC_TYPE_INT8_T
> |     If `stdint.h' or `inttypes.h' defines the type `int8_t', define
> |     `HAVE_INT8_T'.  Otherwise, define `int8_t' to ...
> As you can see, if configure had to define `int8_t', then the symbol
> `HAVE_INT8_T' is not defined.
> So your implementation was wrong, instead of
> +  if test "$ac_cv_c_int$1_t" != no; then
> +    AC_DEFINE_UNQUOTED([HAVE_INT$1_T], [1], [Define if int$i_t exists.])
> +  fi
> you should rather call AC_DEFINE only if "$ac_cv_c_int$1_t" is "yes".

Right - so my intended use of testing HAVE_INT8_T to see whether or
not int8_t could be used was flawed anyway.

> Consistently, when you followed my sugestion and used:
> AC_CHECK_TYPES([uint8_t, size_t])
> then HAVE_UINT8_T would get defined only if `uint8_t' exists on the
> system, not if a substitute was defined by AC_TYPE_UINT8_T.
> AC_CHECK_TYPES([uint8_t]) does not actually perform a second check,
> it uses the findings of AC_TYPE_UINT8_T.
> Observe the output of the configure script:
>       checking for uint8_t... no
>       checking for size_t... no
>       checking for uint8_t... (cached) no
>       checking for size_t... (cached) no
> (You are right, if AC_CHECK_TYPES([uint8_t]) performed the check for
> the second time, it might say "yes", because the just defined
> `uint8_t' macro would have been found.)

Here I have 2 problems:
- I never see uint8_t (cached), and I think this is because
  AC_TYPE_INT8_T uses ac_cv_c_uint8_t, whereas AC_CHECK_TYPES tests
  ac_cv_type_uint8_t, yet you seem to see it - I do see it for size_t...
- but it seems good to test again, as I otherwise I don't see the use-case
  for AC_TYPE_INT8_T.

For a contrived example, say a system doesn't have int64_t but does have
a 64 bit long long int, I was hoping something like the following would do
the right thing:

AC_TYPE_INT64_T             <- finds long long int as suitable for int64_t
AC_CHECK_TYPES([int64_t])   <- sets HAVE_INT64_T, as it is usable given above
                               ? or not ?

#ifdef HAVE_INT64_T
  code using int64_t
  long winded int32_t alternative

So in a sense, I don't care whether int64_t is "native", but just
that it can be used. If AC_CHECK_TYPES doesn't notice the int64_t
defined by AC_TYPE64_T, the 32bit alternative would compile despite
the usable long long int alternative. Is that intended? (It seems
that AC_CHECK_TYPES checks again, so all is well as it is from my
point of view, but is that by accident?)

[... good explanation of #define & confdefs.h ...]
> Hope you find this mosaic of comments useful,

Yes, thank you!


reply via email to

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