[BUILTIN] Use PRIdMAX instead of %j in printf

On 12/03/2012 05:59 PM, Harald van Dijk wrote:
> On 12/03/2012 08:42 AM, Roy wrote:
>> MSYS libc does not support %j[dXx] format, only %ll[dXx] is supported.
>>
>> diff --git a/src/bltin/printf.c b/src/bltin/printf.c
>> index 893295c..12ce660 100644
>> --- a/src/bltin/printf.c
>> +++ b/src/bltin/printf.c
>> @@ -319,11 +319,12 @@ mklong(const char *str, const char *ch)
>>         char *copy;
>>         size_t len;
>>
>> -       len = ch - str + 3;
>> +       len = ch - str + 4;
>>         STARTSTACKSTR(copy);
>>         copy = makestrspace(len, copy);
>> -       memcpy(copy, str, len - 3);
>> -       copy[len - 3] = 'j';
>> +       memcpy(copy, str, len - 4);
>> +       copy[len - 4] = 'l';
>> +       copy[len - 3] = 'l';
>>         copy[len - 2] = *ch;
>>         copy[len - 1] = '\0';
>>         return (copy);
> 
> The calling code uses the result to print intmax_t and uintmax_t values.
> Printing intmax_t values with %lld is wrong, this will only work if
> intmax_t is really a typedef for long long (which may be true on your
> system, but is not required by the standard).
> 
> The other patch that Jonathan linked to should work just fine.

Here's a slightly tweaked version of that patch. Regardless of whether
PRIdMAX is defined as "jd" or as "lld", the use of memcpy here, first
copying "jd"/"lld" and the null byte, and only changing the 'd' after
that, surprisingly results in slightly shorter object code than the
original byte-by-byte approach, even though memcpy is fully inlined.
Perhaps that could be a reason for applying this, even if the original
reason for it, making the code work on not-quite-conforming systems,
isn't good enough to get it in dash.

Tested with normal glibc, and with glibc hacked to not provide PRIdMAX.

Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

0 files changed, 0 insertions, 0 deletions