Re: proposed gnulib-related additions to Autoconf

[Ralf Wildenhues]

Hi Paul,

* Paul Eggert wrote on Wed, Apr 05, 2006 at 09:37:03AM CEST:
> Ralf Wildenhues <address@hidden> writes:
> 
> > First, there is still a bug in both your version and mine, AFAICS: if
> > you pass a MIN-VARIABLE for an unsigned entity, and that variable is not
> > yet defined, it computes the wrong result.
> 
> I assume this can be fixed by replacing:
> 
>                 [$ac_min1 < $ac_min && ($1) $ac_min1 == $ac_min1]
> 
> with:
> 
>                 [$ac_min1 < $ac_min && ($1) $ac_min1 == $ac_min1
>                  && ($1) $ac_min1 < 0]
> 
> so that we don't execute the ac_min=$ac_min1 assignment by mistake.

Yes, I think so.

> > Eric mentioned the desire for a macro to compute all of stdint.
> > So I decided it was worthwhile to have one that does not expand to
> > megabytes of redundant code, even if it was very slow.  Thus the
> > version below allows shell variables as arguments.
> 
> I don't quite follow the motivation here, sorry.  (This is the most
> important point, ...)

Hmm.  I don't understand the part of your reply that is in parentheses.
What are you referring to there?

Which motivation do you not follow?  The one that prompted me to make
the macro work with shell variables?  Well, it's quite a size reduction,
if one wants to compute the ranges for a lot of types.  And I can see
no drawback except slightly increased complexity.


> > Would you rather prefer a BITS-VARIABLE to a VALUE-BITS-VARIABLE, by
> > the way?
> 
> I'm not sure why one would need a bits-variable; can't you just use
> sizeof (type) * CHAR_BIT?

Oh, this is a misunderstanding, sorry.  Let me rephrase the question:
For a signed type that happens to have 46 significant bits, and a
sizeof(type) of `8', would you prefer a VALUE-BITS-VARIABLE containing
`45', or a BITS-VARIABLE containing `46'?  (IOW: the difference is
merely whether the sign bit should be counted in or not.)

> > Currently the VALUE-BITS-VARIABLE is not tested for being defined
> > already.  Should that be included for safety?
> 
> I wouldn't bother, for now.

OK.

> > I tried to accomodate for all that was brought up in the previous
> > discussion.  The testsuite found one more subtle bug: in this code
> >   while :; do
> >    AC_COMPILE_IFELSE([program], [if-true], [break])
> >   done
> >
> > the break will inhibit the cleanup code that removes conftest.c
> 
> I should have remembered that.  We can fix that without using an extra
> status variable by using this sort of idea:
*snip*

Yes, I agree.  Thanks for your replies, very helpful!

Cheers,
Ralf