Paul Eggert wrote on 2006-10-11: > 2006-10-11 Paul Eggert <[EMAIL PROTECTED]> > > Don't assume that 64-bit signed int is available if unsigned int > is, and vice versa. > * lib/allocsa.h (sa_alignment_unsignedlonglong): New constant. > (sa_alignment_max): Don't assume that long long int exists if > unsigned long long int does, and vice versa. > * lib/printf-args.h (TYPE_ULONGLONGINT, argument): Likewise. > * lib/printf-parse.c (PRINTF_PARSE): Likewise. > * lib/vasnprintf.c (VASNPRINTF): Likewise. > * m4/allocsa.m4 (gl_ALLOCSA): Require AC_TYPE_UNSIGNED_LONG_LONG_INT. > * m4/vasnprintf.m4 (gl_PREREQ_PRINTF_ARGS, gl_PREREQ_PRINTF_PARSE): > (gl_PREREQ_VASNPRINTF): Likewise. > * modules/allocsa (Files): Add m4/ulonglong.m4. > * modules/vasnprintf (Files): Likewise.
Now that the Tandem compiler bug is clarified, let me get back to this. It's a bug that makes 'long long' unusable when compiling with optimization. They added a (presumably correct) 'unsigned long long' in 2005. So the only platform that has sizeof (uintmax_t) != sizeof (intmax_t) is this Tandem compiler from 2004, without optimization. Seeing the amount of changes that it costs to support this configuration (and who is interested in unoptimized binaries anyway?), I would find it better to say rightout that we don't support 'long long' in this configuration. This would restore mental sanity for everyone. (Yes, I find it insane to think about signed integers which cannot be casted to corresponding unsigned integers.) Can you agree to that, Paul? I know you worked several hours on this patch, but if we carry it forward, it will cost many more hours of brain cycles in other code, like gnulib, coreutils etc. - for the sole purpose of unoptimized binaries on one particular version of a rare OS. Bruno
