On Fri, Jul 02, 2004 at 07:37:25AM -0700, Paul Eggert wrote: > On the compilers in question, what value does 1/0 return? Perhaps we > can make use of that somehow. On the Compaq CC, the program ``int main() { int c = 1/0; printf("%d\n", c); }'' prints ``0''. > 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....). That yields no diagnostic on the same compiler. Alas. > > 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. Testing both 1/!x and 1/!!x is a great idea. That should flush out most of the cases in which the compiler does not cooperate with our trick of choice. How about this? 2.1. Test { int c[(x) ? 1 : -1]; } 2.2. Test { int c[!(x) ? 1 : -1]; } 2.3. If exactly one of 2.1 and 2.2 fails, use result of 2.1. Else: 2.4. Test { int c = 1/!!(x); } 2.5. Test { int c = 1/!(x); } 2.6. If exactly one of 2.4 and 2.5 fails, use result of 2.4. Otherwise, AC_MSG_ERROR with suggested switched to place in CFLAGS. This should cover all the cases we have observed, prevent a (minute) regression in the next release, and report the cases it does not handle. Another option, should this issue arise again, is to abuse the bit field size expression: struct foo { int bar : (x ? 8 : -8); }; This will probably have the exact same success and failure modes as the array size trick, but I'd be interested to see if Sun CC is kinder to it. _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf