autoconf-patches
[Top][All Lists]
Advanced

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

Re: proposed gnulib-related additions to Autoconf


From: Paul Eggert
Subject: Re: proposed gnulib-related additions to Autoconf
Date: Wed, 05 Apr 2006 00:15:58 -0700
User-agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)

Ralf Wildenhues <address@hidden> writes:

>> +    AC_COMPILE_IFELSE(
>> +      [AC_LANG_BOOL_COMPILE_TRY([AC_INCLUDES_DEFAULT([$4])],
>> +     [$ac_max < $ac_max1 && ($1) $ac_max1 == $ac_max1])],
>
> Strictly speaking, for signed types this invokes undefined behavior, if
> we shifted too far in `$ac_max1', so we can't be certain that the
> outcome of this test will be good to use.  We rely on the fact that in
> practice, this isn't a problem, right?

Yes, that's right.  I doubt whether any host would ever violate this
property.  I don't think C99 + LIA-1 can violate it, and that's sort
of the wave of the future anyway.


> b) If we detect that neither of unsigned int, unsigned long, or unsigned
> long long matches the unsigned type TYPE, we also have to compute the
> number of value bits in `unsigned int'; if that equals the number of
> value bits in TYPE, then we have to add `U'.
>
> Is there maybe a better way?

Can't think of one offhand.

Here's one way to do (b).  More precisely (b) says that if it doesn't
fit in int then you use unsigned:

          if test $ac_1$ac_unsigned = 1unsigned; then
            AC_COMPILE_IFELSE(
              [AC_LANG_BOOL_COMPILE_TRY([AC_INCLUDES_DEFAULT([$4])],
                 [($1) -1 == (int) ($1) -1 && 0 < (int) ($1) -1])],
              [],
              [ac_1=1U])
          fi

>> +        [ac_min='(- $3)'
>> +         ac_min1='(-1 - $3)'
>> +         AC_COMPILE_IFELSE(
>> +           [AC_LANG_BOOL_COMPILE_TRY([AC_INCLUDES_DEFAULT([$4])],
>> +              [$ac_min1 < $ac_min && ($1) $ac_min1 == $ac_min1])],
>
> For signed types, and for unsigned types where the default promotion
> leads to a signed type (note even if above, change (a) was done,
> because $3 may have been already defined, but $2 not), this may again
> invoke undefined behavior.  I assume again that in practice "it works".

Yes, it's the same thing.




reply via email to

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