On 3/26/2018 1:04 PM, Junio C Hamano wrote:
Ramsay Jones <ram...@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
