rapidyaml VS json65

Interesting, I hadn't come across extism before. How hard would it be to package https://github.com/biojppm/rapidyaml in this way? (And do you have a extism for dummies guide?)

The inability, or brittleness, to embed NUL bytes into the string, for once. Zeroed bytes can be valid as an internal bytes of a longer encoded character. And the inefficiency of tempting every caller to rederive the string length on every use, leading to such bugs as quadratic parsing behavior with sscanf. The extra register for an explicit length is a very minute price to pay compared to that.

Although you still have the other problem of sscanf, where read times can become quadratic.

You are really simplifying that issue. A lot of it has to be how the implementation of sscanf works and it's super easy to abuse by complete accident when a lot of data needs to be read and parsed to correct values. See more here: https://github.com/biojppm/rapidyaml/issues/40

Leading to eye-rolling problems like these: https://github.com/biojppm/rapidyaml/issues/40

JSON parser written in 6502 assembly language\ (69 comments)

The "Library organization" section [1] explains that the json65.s file is the core of the library and the only code necessary to build the library. The additional C code provides a handy tree structure and a callback to pass to the parsing engine.

However, because SAX is a callback-oriented parsing method, you can design your own data structure and write your own callback functions and do without this tree structure.

The additional C code provides similar nice-to-haves, such as string pool interning, a function to print out the aforementioned tree structure, and a wrapper function to parse json from a file.

[1] https://github.com/ppelleti/json65#library-organization