Re: [RFC] Refactoring options.c

Am 07.08.2026 um 15:47 schrieb Frank Lichtenheld:
> 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.

I agree on that. If that format should be YAML or some other format, I 
don't have a strong preference but something that is easy to maintain 
and write would be my favourite.

>
> 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 also would not try to put everything such a file. Otherwise you 
reinvent the wheel (badly) as you tend to develop a crude language to 
describe. I would aim to be able to express like 90% of the option and 
the rest gets its own C code like now.

> 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?

Yes. I would like to have a strong seperation between "data" and "code". 
Have the generated data format be a static table and have the actual 
logic/parsing still written by hand similar to the add_option of your 
github page and just use the static generated data to be able to lookup 
thing.

I think having to debug/read generated/super complex code to figure out 
problems is something most of us probably had to do at some point (glib 
2.x is a real horror show ...) and I would try to avoid that.

We might not able to fully avoid that but I would try to have the 
generated code (that has logic) as simple as possible.


Arne