JSON Parser edge & special cases

[vicnaum]

Component

Forge

Have you ensured that all of these are up to date?

• [X] Foundry
• [X] Foundryup

What version of Foundry are you on?

forge 0.2.0 (cb925b1 2022-11-21T00:04:43.554765Z)

What command(s) is the bug in?

parseJson cheats

Operating System

macOS (Intel)

Describe the bug

A discussion started in the forge-std repo about how to determine if the JSON key exists, and which edge cases should return which values: https://github.com/foundry-rs/forge-std/pull/226

Current behaviour of the parser (was verified using parseRaw() function which returns abi-encoded bytes array):

• empty object (as in "returns": {}) is parsed as "0x" abi which just reverts when trying to decode
• null (as in "to": null) is parsed as an empty bytes/string (0x00000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000000)
• empty array (as in "pending": []) is parsed as an empty bytes/string (same as null)

For now there are several propositions from @prestwich:

• Valid solidity types should output valid encodings, while invalid types should output the empty encoding:
• an empty dynamic-length bytes type, encoded as 32 \x00 null bytes
• a null fixed-length bytes type, encoded as 32 \x00 null bytes
• empty array should probably be parsed as the 32 byte \x00 null string

I agree with this, because it will reserve 0x output specifically to non-existent keys. This would allow to distinguish these specific situations when the key exists but is non-solidity-supported type, from a situation where the key doesn't exist in JSON at all.

TLDR: Right now there's no way of differentiating non-existent JSON keys from a key with an empty object {}.

What are the thoughts on above? Let's start a discussion and afterwards can apply a fix (if decided on a fix).

[rkrasiuk]

@odyslam can I assign this to you?

[odyslam]

yes go ahead

[odyslam]

@vicnaum I like @prestwich approach. Wanna attempt a fix? I am tackling a bunch of issues with json cheatcodes, so your contribution would be really valuable.

[rocknet]

empty array should probably be parsed as the 32 byte \x00 null string

Can I ask about this? I'm dealing with an issue at the moment, where the broadcast json files either have arguments: null, if there were no arguments, or it's a string array value. When I try to abi.decode this, assuming I was going to get a string array, it fails if the value was null. Perhaps this belongs as its own issue and the problem is more to do with the json being produced when arguments is null, but I saw this above and wondered if I was always going to have to use two types (one expecting a string array and one expecting a null string). At the moment I'm going to have to do a try / catch, first trying to decode expecting a string array, and second trying to decode to a string. Not the greatest UX, any ideas appreciated here, or perhaps something to keep in mind.