[blueblob]

I don't know if I agree with the premise:

> People are terrified of parsers and parsing

But this implementation of a reduced feature set version of .ini file parsing does not convince me that I should write my own parser instead of using one that implements a more full feature set

> No newlines in keys, values, or section names. Empty values are not allowed. Comments only on their own lines (minus whitespace). Whitespace-insensitive (whitespace at the start of line, end of line, around the “=”, is all ignored). No need for a terminating newline either.

I think it's reasonable that people want to use a parser that has better error handling and gives an idea of where the ini file may have parsing problems than just a barebones implementation such as this provides.

I also think that using a library for parsing instead of writing your own parser does not imply that you are scared of parsing.

[lylejantzi3rd]

> But this implementation of a reduced feature set version of .ini file parsing does not convince me that I should write my own parser instead of using one that implements a more full feature set

A performance comparison on a large ini file might.

You may want to take the time to watch this video[0]. In it, Andreas Fredriksson walks though his reasoning for writing his own parser instead of using the standard json parser.

[0]: https://vimeo.com/644068002

[dezgeg]

Performance comparison of this code might not, however, as fgetc() based parsing is not efficient. (Each call takes a lock in the FILE object).

[delusional]

I don't think the author is necessarily aiming at purpose built file parsers with that statement, but rather "parser generators" like ANTLR.