Hi. I think the current format of options.c is a problem. Much of the logic is hidden in C code, difficult to compare to the documentation, and the if-else-if hell is hard to read, even for some parsers (cppcheck is an example for that).
When adding new options we always go through the same steps and errors (e.g. forgetting to add usage text). So I would guess most people would be open for something better. But how should that look like? I have been looking into a declarative approach with code-generation. We could document the options in e.g. a YAML document and then generate code out of that. Ideally not a repeat of the current code but something a bit better. I was thinking of an getopt_long-style approach with an array that describes the options. One limitation of this approach is that clearly this can only describe a subset of the semantics of the options. Many options have too much logic behind their parsing that can not reasonably be expressed in a declarative way. But I think it still would be much preferable to the current state. I did some manual tests for both the YAML and the options array and then also let write Claude a full spec based on these ideas. You can find it here: https://github.com/flichtenheld/openvpn/blob/options-schema-doc/doc/options-schema.md The interesting part (and what I have mostly reviewed and improved so far) are the actual example results in section 5 (YAML, https://github.com/flichtenheld/openvpn/blob/options-schema-doc/doc/options-schema.md#5-worked-examples) and section 6 (C, https://github.com/flichtenheld/openvpn/blob/options-schema-doc/doc/options-schema.md#6-generated-artifact-shape) Before going any deeper into this rabbit hole I would be curious if people think this general approach could have merit? Or whether there are other ideas where to take this? Thanks, -- Frank Lichtenheld _______________________________________________ Openvpn-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openvpn-devel
