json: fix parsing first array-array element

[M1cha]

No description provided.

[andyross]

So, clearly this needs a commit message to explain what's going on. It's a bug with parsing nested arrays, I guess? Just write up an example of a mis-parsed input string and a quick description of how the fix works. I frankly don't understand how this works at all.

Beyond that, some nitpicking about the code.

[andyross]

Not sure on our stance on utf-8 embedded in C code, but I know this isn't allowed per ISO C and I'm reasonably certain one or more of the various coding standards we try to adopt makes this illegal.

[M1cha]

While you're right, this file used utf-8 before and I'm just following the existing style of the rest of the code.
If we wanna enforce ISO-C utf-8 rules we should add a CI check for it and fix the whole zephyr repo.
That would be out of scope for this PR though.

[d3zd3z]

gcc at least defaults to UTF-8 as the input and string literal encoding. I don't know how this support is in other compilers. But, in this case, this is merely adding an additional test case that is similar to others. Fixing the UTF-8 aspect would be a separate effort.

[andyross]

Why not if (val) { here and skip the changes above? Seems like this is just adding code for no reason.

[M1cha]

IMO it's more natural to check the pointer you're about to write to for NULL instead of some other variable.
Also, the hope is that it prevents bugs caused by future changes, e.g. if element doesn't rely on var anymore.

[andyross]

If you don't pass the string in val down to decode_value(), how does it have anything to parse? Not understanding how this works.

[M1cha]

here, val was just passed through from the argument to this function.
val is just a pointer to the start of the parent struct so arr_parse can do offset calculations.
arr_parse is the only place where this value is actually being used and everyone else just passed it through.

[andyross]

You answered my nitpicks, but not the core question: what does this actually fix? What were we parsing wrong before, and why?

[d3zd3z]

gcc at least defaults to UTF-8 as the input and string literal encoding. I don't know how this support is in other compilers. But, in this case, this is merely adding an additional test case that is similar to others. Fixing the UTF-8 aspect would be a separate effort.

[M1cha]

@d3zd3z Should I do this to fix the compliance check? That looks awkward but it works.

Suggested change

	.n_elements = \
	1 + ZERO_OR_COMPILE_ERROR(elem_descr_len_ == 1), \
	.n_elements = \
	1 + \
	ZERO_OR_COMPILE_ERROR( \
	elem_descr_len_ == 1 \
	), \

[d3zd3z]

That's probably reasonable. This code is kind of overly deep anyway, but we're not about fixing that aspect.