Re: [RFC PATCH 1/1] json-writer: incorrect format specifier

From: Jeff Hostetler <git@jeffhostetler.com>
Date: Mar 26, 2018, 17:39 UTC
Message-ID: <db400047-ac2e-100c-8d5a-12f1d05b93be@jeffhostetler.com>
In-Reply-To: <xmqqr2o6dayt.fsf@gitster-ct.c.googlers.com>

On 3/26/2018 1:04 PM, Junio C Hamano wrote:

Show 25 quoted lines

> Ramsay Jones <ramsay@ramsayjones.plus.com> writes:
> 
>>>> @@ -120,7 +120,7 @@ void jw_object_uint64(struct json_writer *jw, const char *key, uint64_t value)
>>>>   	maybe_add_comma(jw);
>>>>   
>>>>   	append_quoted_string(&jw->json, key);
>>>> -	strbuf_addf(&jw->json, ":%"PRIuMAX, value);
>>>> +	strbuf_addf(&jw->json, ":%"PRIu64, value);
>>>
>>> In this code-base, that would normally be written as:
>>>
>>> 	strbuf_addf(&jw->json, ":%"PRIuMAX, (uintmax_t) value);
>>
>> heh, I should learn not to reply in a hurry, just before
>> going out ...
>>
>> I had not noticed that 'value' was declared with an 'sized type'
>> of uint64_t, so using PRIu64 should be fine.
> 
> But why is this codepath using a sized type in the first place?  It
> is not like it wants to read/write a fixed binary file format---it
> just wants to use an integer type that is wide enough to handle any
> inttype the platform uses, for which uintmax_t would be a more
> appropriate type, no?
>

[Somehow the conversation forked and this compiler warning appeared in both the json-writer and the rebase-interactive threads. I'm copying here the response that I already made on the latter.]

I defined that routine to take a uint64_t because I wanted to pass a nanosecond value received from getnanotime() and that's what it returns.

My preference would be to change the PRIuMAX to PRIu64, but there aren't any other references in the code to that symbol and I didn't want to start a new trend here.

I am concerned that the above compiler error message says that uintmax_t is defined as an "unsigned long" (which is defined as *at least* 32 bits, but not necessarily 64. But a uint64_t is defined as a "unsigned long long" and guaranteed as a 64 bit value.

So while I'm not really worried about 128 bit integers right now, I'm more concerned about 32 bit compilers truncating that value without any warnings.

Jeff