Re: Overflow protection in _AC_COMPUTE_INT_COMPILE

[Akim Demaille]

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

That's perfect comments :)

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

You can.

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

Just nothing at all, that's enough.


| > 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)]
| 

Then *that*'s the true problem.  I mean your protection is an
excellent thing, but that's an improvement of what we had.  Here we
have a real problem, and this is what must protect ourselves from.  So
first, we need to characterize the problem.

Is it that sizeof is not resolved at compiled time with this compiler?
What is it that it refuses?  Once we know that, we will be able to
first check we can use this technique, and use the traditional
fall back.

This is also why I asked if you tried the switch/case technique.

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

OK.

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

Yep, I might have an access to such a machine at ENST, I'll try to
find out.

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

OK.

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

That's right, but notice the `_INT_' :)