Re: proposed gnulib-related additions to Autoconf

[Paul Eggert]

Ralf Wildenhues <address@hidden> writes:

> If it's not too much work for you, it would be great if you could change
> the end of the macro to
>   )# AC_C_LONG_DOUBLE
>
> and similarly for the other macros, at least the longer ones.

OK, I'll do that.

>> +m4_define([AC_C_TYPE_RANGE_INTEGER],
>
> This needs to be AC_DEFUNed.

Will do.

> ac_1 should be initialized to 1 right before this loop; even if the
> other change below is made (otherwise for `short' it could end up empty).

Thanks for that.

>> +          "$ac_unsigned int" \
>> +          "$ac_unsigned long int" \
>> +          "$ac_unsigned long long int"; do
>
> Couldn't the type we are looking at be incompatible with any of these,
> say an intmax_t?  at_1="${ac_suffix}INTMAX_C(1)" would come in handy
> below then, if it were defined.

But that should be another arg, right?  We can't enumerate all the
possibilities.  Hmm, are there practical concerns here right now, or only
theoretical at this point?

> That thing should not be called foo.

OK, I'll change it to ac_$3.

>> +          [ac_1=$ac_1$ac_suffix
>
> I think this is better written as
>                ac_1=1$ac_suffix

Yes, thanks.

>> +           case $ac_type in #(
>> +           *'long long'*) ac_1=${ac_1}LL;; #(
>> +           *long*) ac_1=${ac_1}L;;
>> +           esac
>> +           break])
>> +      done
>> +
>> +      ac_bits=8
>
> I'm a bit on shaky grounds here, but: if we know we need long or long
> long above, can't we increase the minimum ac_bits we start off with,

No, because shorter-than-int types promote to int.  The suffixes are
for the promoted values.  For example, if the type is 'short', then
'(1 << 15) - 1' is a suitable maximum value, even though its type is
'int' rather than 'short'.

>> +      ac_shiftbits=`expr $ac_bits - 1 - $ac_signbits`
>> +      ac_max="(((($ac_1 << $ac_shiftbits) - 1) << 1) + 1)"
>
> The next two block could use just a binary search after the initial
> doubling and do things once.  Pure optimization though.

Yes, I didn't bother because the optimization is needed only
on 36-bit hosts and the like, and these are so rare I don't
worry about the speed of finding their maximum values.

> | +     # Add 1 to the number of bits until this fails.
> | +     while :; do
> | +       ac_bits1=`expr $ac_bits + 1`
>
> Erm, ac_bits won't ever be changed in this loop, so this will loop
> forever, iff the loop would have to be executed more than once.

Thanks, I've rewritten that.

> If you don't mind, I'll suggest a rewrite and some factorization of this
> macro that also allows to get at the number of value bits (may be a day
> or two though).

OK.

>> +# AC_TYPE_RANGE_LONG_LONG_INT
>> +# ---------------------------
>> +AC_DEFUN([AC_TYPE_RANGE_LONG_LONG_INT],
>> +  [AC_C_TYPE_RANGE_INTEGER([long long int], [LLONG_MIN], [LLONG_MAX])])
>> +
>> +
>> +# AC_TYPE_RANGE_UNSIGNED_LONG_LONG_INT
>> +# ------------------------------------
>> +AC_DEFUN([AC_TYPE_RANGE_UNSIGNED_LONG_LONG_INT],
>> +  [AC_C_TYPE_RANGE_INTEGER([unsigned long long int], [], [ULLONG_MAX])])
>
> Shouldn't these macros include limits.h if present?

They should include <limits.h> unconditionally.  (Let's not support
K&R C in new macros.)  Thanks for catching that.