Re: AC_LANG_BOOL_COMPILE_TRY(C) fails with OS vendor compilers

[Paul Eggert]

Noah Misch <address@hidden> writes:

> That said, I'd like to fix it.  Would one of the following be appropriate?
>
> 1) Change the test such that it creates truly invalid C in the false case.  I
>    don't know how to do this, but perhaps a reader does.  Ideas?

Unfortunately there's no such thing as "truly invalid C", in the sense
that every possible C compiler, whether conforming or not, will exit
with nonzero status when asked to compile it.  This is because people
are free to add extensions.  The best we can do is to write code that
fails on all practical implementations.

On the compilers in question, what value does 1/0 return?  Perhaps we
can make use of that somehow.

Another possibility: perhaps these troublesome compilers reject
arithmetic overflow?  For example, do they reject the expression
((short int) 2147483647)?  We could evaluate this expression in
addition to 1/0.  The reason I'm suggesting this is that the C
standard requires a diagnostic for overflow, but not for division by
zero (strange but true....).

> 2) Test for the switch (including none) that makes the compiler
> driver return a nonzero status when a division by zero exists in the
> code.

I'd rather not head down that path: it's too much maintenance hassle.

How about this idea instead?

1.  For native compiles, compile, link, and run a program that prints
1 or 0 depending on whether x is nonzero.  This avoids the problem.

2.  For cross-compiles, use the current strategy, but evaluate both
1/!x and 1/!!x.  If both expressions compile, we have a troublesome
compiler like HP's, so reject the compiler and abort the invocation of
"configure".  In the error message, suggest to the user that they find
an option to make the compiler work right, and give the known flags as
examples.

3.  File a bug report with HP.  'static int x = 1/0;' should not
compile by default.  I'm surprised that it does, and I'll bet most
other programmers are too.  (Tell them that their current behavior is
incompatible with Autoconf.  :-)