Re: Overflow protection in _AC_COMPUTE_INT_COMPILE

[Akim Demaille]

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

I'm sorry, I still don't understand why you emphasize on the
cross-compiling issue here.  It is true that _AC_COMPUTE_INT uses two
different approaches depending whether cross-compiling or not, but
it's only an optimization.  We don't need cross-compilation at all.
Just run

        ./configure cross_compiling=yes

and you'll trigger this test even we regular compilers.

Really, please, explain why you pay so much attention to
cross-compilation.


| > 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 */

Yep, sorry, that's what I meant.

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

Nope, _AC_COMPUTE_INT_COMPILE is used when cross-compiling, otherwise
we just save the result in confval, and read it back.

Maybe I'm starting to understand what you mean.  Since this code is
triggered only when cross-compiling, we don't care about it's failure
on a compiler as stupid as the bundled cc, right?



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

It is not that much arbitrary: _AC_COMPUTE_INT_COMPILE was expected to
work *everywhere*.  So we do have a problem.

IIRC Kaveh is using similar macros in GCC, but he uses the
case-technique.  I'd be interesting to check whether it works better,
or how he deals with the bundled CC.  Using AC_TRY_RUN is considered
an optimization, so it does matter to know that in some cases it is no
optimization but a workable solution.