Mark H Weaver writes: > Hi Chris, > > I'm terribly sorry for the long delay on this. For better or worse, > I've become extremely concerned about computer security, and so I feel a > heavy responsibility to be extra careful about code that is expected to > parse hostile data.
No worries. I also know you've been working hard to keep us secure in your work on Guix and etc, and all that work is valued / appreciated! > I was also looking for a cleaner way to express this parser, and to add > better error reporting, while allowing flexibility for users to > customize the Scheme representation. Toward these ends, I ended up > re-implementing the parser from scratch. > > I've attached my current draft of the new parser. By default, JSON > objects are represented as (@ . <alist>) where <alist> has dotted pairs, > but it's easy to ask for your preferred two-element lists using > 'make-json-parser'. I like the interface to make-json-reader. It looks like it would work well by default, but it's also obvious to me how to extend it. It also looks far less disasterous than my attempt to be flexible on using fashes or s-exps via an overdose of if clauses. ;) Looks good! > The json writer is mostly okay, but it also needs to be generalized to > support the customizable representation (and maybe I went too far here > with the parser, dunno). I don't see the writer included below? > Also, there are a few cases where it will generate invalid JSON, > notably: if ASCII control characters are present in strings, hex > escapes must be printed instead of the raw character, and real numbers > cannot simply be printed using 'display' because of infinities and > NaNs. > > Are you okay with this general direction? I'm good with it! It's a bit more complicated to read than David's original design but it looks well formed (and I followed it well still), and I'm confident in your reasoning behind its design. I feel like the flexibility of plugging in different datastructures as needed is a big win, anyway. Speaking of security issues, I've wondered before about someone giving a json structure so large or deeply nested that it's hard to fit in memory (maybe a structure that even just looks like "[[[[[[[[[[[[[[[[[[[[[[..."). Maybe a recursive limit, or some other type of limit, would be useful? but I imagine that could complexify the design considerably, and maybe it's not worth it. I tested this on a few examples from https://www.w3.org/TR/activitystreams-vocabulary/ and they all seemed to work fine. Thanks for all your hard work on this! Looking forward to seeing this land! - Chris PS: > ;; XXX Consider using conditions and exceptions from SRFI-34 + SRFI-35 > ;; or R6RS (they should be merged!) Yeah I've wondered about this... I've come to the point where I needed the kind of condition subtyping that srfi-35 and r6rs conditions provide, but I'm not sure which one to use. Advice?