Paul Eggert <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> 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?
