Hi Lucas
On 08/07/2025 20:27, Lucas Seiki Oshiro wrote:
These all look like good changes. Looking through this series I do think that
it would be more readable and maintainable if you adopted the table drive
approach suggested by Junio.
Today I had a meeting with my mentors (Karthik and Patrick), and yeah, this is
something that I'll change in v4.
That's great
Returning the keys in the same order as they were requested in the
null-terminated format is not so useful now that I'm keeping the keys in the
output. Dropping this assumption allows me to make this code simpler.
That way we would avoid the nested switch statements and each piece of
information only needs to be retrieved once rather that having to retrieve it
separately for the JSON and plaintext output. Below is a sketch of might look.
Each key is handled by a callback and we have a table that maps key names to
callbacks. For the json output we use one json writer per category to build
output for each category.
At first glance it looks good to me. It still seems to me that it needs to
somehow treat duplicated keys.
We can detect duplicate keys by adding an array
char seen_key[ARRAY_SIZE(handle)];
and checking to see if we've already set `seen_key[j]` in the inner
loop. We should also detect invalid keys which we can do by setting a
flag when we find the key or by moving the declaration of `j` into the
outer loop and checking that `j < ARRAY_SIZE(handle)` at the end of the
inner loop.
Thanks
Phillip
