Richard Laager via devel <devel@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. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel