Don't insist on 'long long int' support in the preprocessor. It
authorPaul Eggert <eggert@cs.ucla.edu>
Mon, 12 Nov 2007 23:50:17 +0000 (15:50 -0800)
committerPaul Eggert <eggert@cs.ucla.edu>
Mon, 12 Nov 2007 23:50:17 +0000 (15:50 -0800)
commit2fd369d04b4b9022ee48695882bf98d2d51a33dd
tree14b93bbc760c76030b060b02655fd0b2de63015f
parenta635ca9c01d6e9a747ac9c0c2eed04658486d400
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.
* m4/longlong.m4 (_AC_TYPE_LONG_LONG_SNIPPET): Don't test the
preprocessor.
* m4/inttypes.m4 (gl_INTTYPES_H): Move the #if checks into
compile-time C checks, done at 'configure'-time.
(gl_INTTYPES_CHECK_LONG_LONG_INT_CONDITION): New macro.
* modules/inttypes (Makefile): Substitute the new symbols that
gl_INTTYPES_H now generates.
* lib/inttypes.in.h: Don't use constants wider than 'long' in #if.
ChangeLog
lib/inttypes.in.h
m4/inttypes.m4
m4/longlong.m4
modules/inttypes