+2007-11-12 Paul Eggert <eggert@cs.ucla.edu>
+
+ Don't insist on 'long long int' support in the preprocessor. It
+ breaks too many things. For example, PRIdMAX still uses a 'long
+ long int' format with the latest Sun compiler, even though
+ HAVE_LONG_LONG_INT isn't defined due to that compiler's
+ preprocessor problem. This causes the latest coreutils to dump
+ core on Solaris 10 sparc with the Sun C compiler.
+ Instead, fix the 2007-10-16 problem in a different way, by evaluating
+ the troublesome expressions at configure-time, not at #if-time.
+ * longlong.m4 (_AC_TYPE_LONG_LONG_SNIPPET): Don't test the
+ preprocessor.
+
2008-08-17 Bruno Haible <bruno@clisp.org>
* threadlib.m4: New file, from gnulib.
AC_DEFUN([_AC_TYPE_LONG_LONG_SNIPPET],
[
AC_LANG_PROGRAM(
- [[/* Test preprocessor. */
- #if ! (-9223372036854775807LL < 0 && 0 < 9223372036854775807ll)
- error in preprocessor;
- #endif
- #if ! (18446744073709551615ULL <= -1ull)
- error in preprocessor;
- #endif
+ [[/* For now, do not test the preprocessor; as of 2007 there are too many
+ implementations with broken preprocessors. Perhaps this can
+ be revisited in 2012. In the meantime, code should not expect
+ #if to work with literals wider than 32 bits. */
/* Test literals. */
long long int ll = 9223372036854775807ll;
long long int nll = -9223372036854775807LL;