Open alexhenrie opened 3 years ago
Interesting proposal. Have you checked that JSMN never really depends on those default values in cases such as missing JSON?
Two of the three calls to json_fill_token
are immediately after json_alloc_token
. The only place where json_fill_token
is called later, and therefore behavior could change, is when JSMN_STRICT
is defined and an object or array is used as a key. In that case, token->type
was previously uninitialized and token->start
was initialized to -1
before returning JSMN_ERROR_INVAL
. With this patch, token->type
and token->start
are set before erroring out.
JSMN itself doesn't do anything with those values before returning, so really we're just talking about what the caller should see if the caller looks at the tokens despite jsmn_parse
returning JSMN_ERROR_INVAL
. In my opinion, initializing the last token (the bad key) with accurate values before returning an error is more useful than leaving the values uninitialized or invalid. However, if it's important, I could easily reset token->type
to JSMN_UNDEFINED
and token->start
to -1
on the error path. Just let me know and I'll modify the pull request.
JSMN has been initializing tokens with default values, then initializing them again with the real values. The first step can be skipped to make JSMN smaller and faster.