microjson vs. libjsmn

[Eric S. Raymond]

Richard Laager via devel <devel at ntpsec.org>:
> On 3/7/19 12:56 AM, Eric S. Raymond via devel wrote:
> > JSON is C is normally *very* awkward, vastly worse than Go, because
> > full JSON parse needs to do fancy dancing with dynamic memory to
> > handle heterogenous arrays. The good news is that I ran into this
> > problem back in 2009 on GPSD, solved it then and spun it out as a
> > little library, microjson.
> 
> ntpsec is already using (and embedding) libjsmn, right?

Yes.  The difference is that libjsmn isn't an entire deserializer the way
microjson is.  It's really only the lexical analyzer for a deserializer; you
have to hand-roll the upper level, including the data copies (the risky part
from a security and assurance POV).

microjson does the whole job, going from JSON all the way to data
unpacked into structs without any hand-written executable code. The
cost is that you have to utter some compile-time declarations to tell
it how to work.

This is better because it means that you can unit-test microjson,
audit its code, and get from that stronger evidence of correctness in
any particular deployment than you can have about a hand-rolled
deserializer.

(Ian, there's a general principle here.  Explain it.  Try to give an example
of how you would apply it elsewhere.)

Dropping libjsmn to replace it with a (possibly slightly customized)
version of microjson.c has been on my list of things to do maybe?  

Note to self: write program that can parse a C structure declaration and
generate from it the compile-time declarations microjson requires.

Further note to self: turn microjson into a code generator that omits support
for types and features not required by individual deployments. 
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.