Re: [bug-gnulib] proposed patch to allocsa, vasnprintf for Tandem NSK (OSS)

[Bruno Haible]

Paul Eggert wrote on 2006-10-11:
> 2006-10-11  Paul Eggert  <address@hidden>
> 
>       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