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

Ramsay Jones [off-list ref] writes:

quoted

quoted

@@ -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?

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

Ramsay Jones [off-list ref] writes:

quoted

quoted

quoted

@@ -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

On 26/03/18 18:04, Junio C Hamano wrote:

Ramsay Jones [off-list ref] writes:

quoted

quoted

quoted

@@ -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?

I must confess to not having given any thought to the wider
implications of the code. I don't really know what this code
is going to be used for. [Although I did shudder when I read
some mention of a 'universal interchange format' - I still
have nightmares about XML :-D ]

ATB,
Ramsay Jones

On 3/26/2018 11:26 PM, Ramsay Jones wrote:

On 26/03/18 18:04, Junio C Hamano wrote:

quoted

Ramsay Jones [off-list ref] writes:

[...]

I must confess to not having given any thought to the wider
implications of the code. I don't really know what this code
is going to be used for. [Although I did shudder when I read
some mention of a 'universal interchange format' - I still
have nightmares about XML :-D ]

[...]

My current goals are to add telemetry in a friendly way and
have events written in JSON to some audit destination.
Something like:

     { "argv":["./git","status"],
       "pid":84941,
       "exit-code":0,
       "elapsed-time":0.011121,
       "version":"2.16.2.5.g71445db.dirty",
       ... }

Later, we could add a JSON formatter to a command like "status"
and then do things like:

     $ git status --json | python '... json.load ...'

and eliminate the need to write custom parsers for normal
or porcelain formats.  There are other commands that could
be similarly adapted and save callers a lot of screen-scraping
code.  But that is later.

Thanks,
Jeff