Re: proposed gnulib-related additions to Autoconf

[Ralf Wildenhues]

Hi Paul,

* Paul Eggert wrote on Fri, Mar 31, 2006 at 09:10:25AM CEST:
> Ralf Wildenhues <address@hidden> writes:
> 
> 
> >> +        "$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?

Yes.

> We can't enumerate all the possibilities.

Yes.  If a system has something strictly between long long and intmax_t,
we lose.  I'll give that a decade, though.  :-)

> Hmm, are there practical concerns here right now, or only
> theoretical at this point?

Even that is theoretical at this point: I do not know of a system that
has an intmax_t that is larger than long long.  But AFAIK C99 allows it.

> > That thing should not be called foo.
> 
> OK, I'll change it to ac_$3.

That's fine.

> >> +         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'.

That's why I only suggested it for long and long long, not for int.
But maybe I'm still missing something else here.

> >> +    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.

That's fine.

The rewrite is still pending.

Cheers,
Ralf