Re: Overflow protection in _AC_COMPUTE_INT_COMPILE

[Pavel Roskin]

Hello, Akim!

> | This patch should eliminate the last testsuite failure on HP-UX 10.20 with
> | CC=cc (where cc is the "bundled" compiler).
>
> Good news, but could you detail what you are doing.  I mean, I trust
> your fix, but I want to understand it: comments are missing.

If [($1) <= $ac_try])] is always false, i.e. $1 is a very big number then
$ac_lo will grow until it becomes negative. When it happens, it makes no
sense to continue. At this point, $ac_try is being set to an empty value
to indicate the failure, and "break" ends the "while" loop ("case" in
shell is transparent to "break", unlike C).

I considered having a separate variable, e.g. ac_try_error, but ac_try
seems to be a good choice since it's always set if the boundary is
successfully found.

In the same way, if [($1) <= $ac_try])] is always true, then $ac_hi would
become positive at some point. If there is no "-" in $ac_hi then we do the
same - break out of the loop.

> | Index: ChangeLog
> | --- ChangeLog       Tue Nov 14 21:02:08 2000
> | +++ ChangeLog       Wed Nov 15 00:43:26 2000
> | @@ -1 +1,6 @@
> | +2000-11-15  Pavel Roskin  <address@hidden>
> | +
> | +   * acgeneral.m4 (_AC_COMPUTE_INT_COMPILE): Protect against overflow
> | +   in expr.
> | +
> |  2000-11-14  Paul Eggert  <address@hidden>
> | Index: acgeneral.m4
> | --- acgeneral.m4    Tue Nov 14 21:02:09 2000
> | +++ acgeneral.m4    Wed Nov 15 00:41:18 2000
> | @@ -3054,16 +3054,27 @@
> |  AC_COMPILE_IFELSE([AC_LANG_BOOL_COMPILE_TRY([$3], [($1) >= 0])],
> |   [ac_lo=0 ac_try=0
> |    while :; do
> | +    case x$ac_lo in
>
> There is no reason to x here.

I wanted to make sure that "case -2147483648 in" will not treat
"-2147483648" as a switch to "case".

I'll drop it if you are sure that it's useless.

> | +      *-*) ac_try=
> | +           break ;;
> | +    esac
> |      AC_COMPILE_IFELSE([AC_LANG_BOOL_COMPILE_TRY([$3], [($1) <= $ac_try])],
> |                     [ac_hi=$ac_try; break],
> |                     [ac_lo=`expr $ac_try + 1`; ac_try=`expr 2 '*' $ac_try + 
> 1`])
> |    done],
> |   [ac_hi=-1 ac_try=-1
> |    while :; do
> | +    case x$ac_hi in
>
> nor here.
>
> | +      *-*) ;;
> | +      *) ac_try=
> | +         break ;;
> | +    esac
> |      AC_COMPILE_IFELSE([AC_LANG_BOOL_COMPILE_TRY([$3], [($1) >= $ac_try])],
> |                        [ac_lo=$ac_try; break],
> |                        [ac_hi=`expr $ac_try - 1`; ac_try=`expr 2 '*' 
> $ac_try`])
> |    done])
> | +test "x$ac_try" = x && \
>
> Please, don't `\'.

I just wanted not to exceed 80 characters. What is your favorite way of
doing it? dnl?

> | +  AC_MSG_ERROR([Cannot evaluate `$1' while cross-compiling], 77)
>
> s/Cannot/cannot/.

Ok

> I don't understand this message.  The point of this macro is precisely
> that it allows us to compute results with just the compiler, including
> when cross-compiling.

Right, but you must have a good compiler for that (gcc will do). The HP-UX
compiler always fails when it encounteres constructs like

int _array_ [1 - 2 * !((sizeof(int)) <= 4095)]

I don't have access to that machine anymore, but if I remember correctly,
the message was about an array of variable size.

The compiler shipped with HP-UX (the so-called "bundled" compiler) is very
primitive. It doesn't support ANSI C at all. There is another compiler,
ANSI C, but it costs money (at least I couldn't find it for free).

>From what I know about the "bundled" compiler it is not unlikely that it
cannot reduce ((sizeof(int)) <= 4095) to an integer at the compile time,
i.e. it possibly emits the code that actually does the calculation at the
run time.

Given all the above, we cannot assume that _AC_COMPUTE_INT_COMPILE will
always succeed, therefore we must handle the case when it fails.

Besided, think of:
_AC_COMPUTE_INT_COMPILE([1e+50])
_AC_COMPUTE_INT_COMPILE([-1e+50])

There is no portable way to work with 1e+50 in "expr".

Regards,
Pavel Roskin