Re: printf-parse: Handle a PRIdMAX value of "qd" (for MacOS X 10.3).

[Jim Meyering]

Paul Eggert <address@hidden> wrote:

> Jim Meyering <address@hidden> writes:
>
>> I have mixed feelings about this patch.
>> Sure, it probably works, but adding support for the non-standard
>> %qd specifier seems wrong.  Maybe it'd be better to make
>> gt_INTTYPES_PRI declare such a PRIdMAX value invalid and to
>> provide a replacement definition.
>
> Another possibility (though this will require a bit more contortion,
> to get access PRIdMAX) is to change the test from:
>
>                 else if (*cp == 'q')
>
> to:
>
>                 else if (PRIdMAX[0] == 'q' && *cp == 'q')
>
> That way, with a decent optimizing compiler we won't add support (and
> runtime overhead) for the nonstandard specifier except on platforms
> that seem to require it.

Thanks for the feedback, Paul.
Using the PRIdMAX[0] guard sounds worthwhile, if it's easy to do.
I haven't looked.

> If that idea doesn't work for you, I mildly prefer just installing the
> patch with 'q' and stopping there, since that works and it's simple.
> There is some precedent for supporting nonstandard extensions, e.g.,
> the code already supports 'Z'.

I too like the idea of the simple fix right now,
so I can make a stable coreutils release without
new and less-well-tested gnulib/autoconf machinery.

Bruno, what do you think?