> then I'm pretty sure I can write something a lot more efficient Sure. > and portable ...it's hard to be "a lot more portable" than a simple C library that

> then I'm pretty sure I can write something a lot more efficient Sure. > and portable ...it's hard to be "a lot more portable" than a simple C library that compiles out of the box on all your preferred compilers and platforms. Care to elaborate how you end up being "a lot more portable"? > with better error reporting Plenty of room to do your own error reporting with off the shelf parsers. > and I can do it in 10 minutes The bug reports, on the other hand, will last a lifetime. Because that format will change, your underlying assumptions will be invalidated, and your parser will eventually grow into one of the 4+ fully featured redundant XML parsers in your project, each with their own set of weird assumptions, inconsistencies, and "supported bugs" (for backwards compatibility), and all of them will need to be maintained. At least until someone takes the time to make a breaking change to the data format, and rip them out to replace them with a proper off-the-shelf JSON parser that has orders of magnitudes more eyeballs fixing the corner cases. Then you'll only have 3+. > A full XML parser comes with a whole ton of bloat you don't need for that! I'll take minor binary bloat over major maintenance bloat any day. And you're wrong: It turns out I actually need a lot of that "bloat" in the next revision. > Plus, if there's ever a problem with those files, the outsourced XML parser will tend to give the end-user absolutely useless error messages. If you have a blindly auto-generated XML-to-binary-format reflection based converter, sure. That's not a good reason to write off "off the shelf" XML parsers outright though, when there's plenty of ways to use them that will give you perfectly fine error messages. To keep with your theme of generalizations: in-house XML parsers tend to give the end-user no error messages, which is far worse ;)