(QUESTION) json_extract() behavior

[lcsmuller]

1. How does json_extract() deal with dynamically typed JSON? For example:

var foo=0;
json_extract(payload, sizeof(payload), "(var):d", &foo);

Here foo expects that the type of var is of a integer. What is going to happen if, for example, var ends up being a string? Will the program crash, or will the assignment be ignored and move on? If the program crashes, I think a more desirable behavior would be to compare the jsmn type with the specifier provided. In this example we have a d specifier which corresponds to a int type, so the comparison would end up being:

// don't crash, but ignore
if (jsmn_tok->type == JSMN_PRIMITIVE && a->_.builtin == B_INT) {
  ...
}

Crashing is not ideal when dealing with APIs that don't "respect" their docs specifications. Any non-conforming JSON is enough to crash the program.

[mlite]

Yes, it should not crash. Is it possible to catch this error?

[lcsmuller]

Yes, it should not crash. Is it possible to catch this error?

Not without changing the function signature. A alternative would be implement a new argument switch to store unmatching fields, like so:

char *buf;
char **p_buf = &buf;
json_extract(payload, sizeof(payload),
  "(var):d"
  "@record_leftover",
  &foo,
  p_buf); // if 'p_buf' is not NULL, we will dynamically increase the size of '*p_buf' by concatenating the leftover JSON

If 'var' type doesn't match the specifier 'd' (int), then buf contents will be a object containing all the leftover key/value pairs. In this example, if var type is 'string', then 'buf' would be filled up like this:

{ "var": "A String" }

Then we are free to parse that in whatever library we want to

[mlite]

This is the signature of the current function

extern size_t  json_extract (char * json, size_t size, char * extractor, ...);    

we can change it to

extern int json_extract (char * json, size_t size, char *strerr, char * extractor, ...);    

returning value -1 represents error, 
if strerr is NULL, we don't report the actually error, otherwise we copy over the error message

The another issue is we need to define a fixed length for strerr.

[mlite]

another design is that we keep any internal state

extern struct state* json_actor_init();
extern int json_extract (struct state *state, char * json, size_t size, char * extractor, ...);    
extern void json_actor_err(struct state *state, char * error);

This is not a good idea, and it's too verbose.

[lcsmuller]

another design is that we keep any internal state

extern struct state* json_actor_init();

extern int json_extract (struct state *state, char * json, size_t size, char * extractor, ...);    

extern void json_actor_err(struct state *state, char * error);

This is not a good idea, and it's too verbose.

Hmmm I like this one

[lcsmuller]

Its more flexible should we ever want to add anything new to the state, we won't have to refactor the function signature

[mlite]

can we use the errno approach for the error message? This extract context is too cumbersome to use.

[lcsmuller]

Sure, how about just returning a negative number as you suggested? We can create json_strerror() for printing the error description

[mlite]

Yes, this is more friendlier and C idiomatic.

…

On Aug 29, 2021, at 3:47 PM, Lucas Müller ***@***.***> wrote:  Sure, how about just returning a negative number as you suggested? We can create json_strerror() for printing the error description — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.