Re: Overflow protection in _AC_COMPUTE_INT_COMPILE

[Pavel Roskin]

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

The _real_ problem would be with a compiler _really_ capable of
cross-compiling.

> Is it that sizeof is not resolved at compiled time with this compiler?

I don't think so. It would be very bad, since sizeof cannot be resolved at
the run time either. Try step-by-step:

int _array_ [(sizeof(int)]             /* I guess this should succeed */
int _array_ [((sizeof(int)) <= 4095)]  /* ... but not this */
int _array_ [!((sizeof(int)) <= 4095)]
int _array_ [2 * !((sizeof(int)) <= 4095)]
int _array_ [1 + 2 * !((sizeof(int)) <= 4095)]

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

_AC_COMPUTE_INT_COMPILE is already a fallback. If it fails there is
nothing else that we can do.

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

I don't want to change the real code as a result of problems in the
testsuite caused by an arbitrary "cross_compiling=yes"

On the other hand, in may be a good idea to protect against the compilers
that cannot calculate

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

(note the plus) by a separate check.

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

It's /bin/cc, not /opt/ansic/bin/cc

> | _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_' :)

Just did it :-)

Regards,
Pavel Roskin