hammer

rolling our own crypto) we can handle device exploitability with well-described data and automated parser generation from those descriptions (and not rolling our own parsers, which these folks say should be verboten for the same reason as rolling one's own crypto: parsing is too hard for non-specialists to get right). Moreover, we don't have to redo the whole stack for it to be meaningful: big players can start using this tooling (e.g. https://github.com/UpstandingHackers/hammer) for parsers handling data from very untrustworthy inputs, such as message payloads sent to a phone number. Apple's Lockdown mode is a step in this direction, though in such a crude, "burn the village" way that it makes the phone almost unusable. But sacrificing usability shouldn't be necessary with current methods. If these folks can make safe parsers for PDF (https://www.darpa.mil/program/safe-documents) it should be possible for anything. Another great talk: https://www.youtube.com/watch?v=3kEfedtQVOY

remember state. It's also redundant information, creating the possibility of a miss-match between the number specified in "numPersons" and the actual number of rows. A format that uses s-expressions would be safer and more easier to implement: (ancestry (ancestor (person john "John Doe") (person jane "Jane Doe") ) ) The closing tag of the s-expression provides a similar benefit as the num* fields by simply marking the end of a complete record/field. > That's so trivial that I would never want to depend on a parser generator Is it really "trivial"? Or is your parse that you write in 10 minutes accepting ambiguous or invalid data? Is it actually checking for all of the error conditions? For most real-world grammars, it's unlikely you will catch all of the subtle ambiguities, interactions, and edge cases. The benefit of using a parser generator is that those entire classes of bugs are impossible. > check (relational) integrity In the trivial example you gave, you shouldn't have a grammar that requires checking relational integrity. In a more complex grammar, such checks would be the job of whatever is walking the AST that the parser returns. Parsers interpret syntax, not semantics. > If I leave away the num* fields above, the parser would need one token of lookahead. You need at least one token of lookahead anyway. Including the num* fields means the parser needs to remember and manage state. [2] https://github.com/UpstandingHackers/hammer