Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Enforce the is_node_list contract in lib-config setters. #581
imo the config file should be fixed up instead and g_critical be thrown, similar to https://github.com/irssi/irssi/blob/master/src/lib-config/set.c#L108
That doesn't really matter, we have had users accidentally corrupt their config files quite similarly to the fuzz. By fix in this case I mean removing and overwriting the incorrect node with a fresh one of correct type. Otherwise settings would be permanently broken Am 29. November 2016 23:19:53 MEZ, schrieb dx <firstname.lastname@example.org>:…
>imo the config file should be fixed up How can we fix something that wasn't intended to make sense? This thing is just the result of fuzzing, not actual user mistakes. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #581 (comment)
-- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
So i tested with this config
And applying both this PR and the other one results in these visible errors:
And it saves to:
Which loads just fine afterwards.
So, merge both?
The second commit tries to save the date by nuking the parent node and re-creating it in place as a list/block one. I'm not 100% sold on the usefulness of this approach since we're substituting a broken and syntactically invalid configuration with a now syntactically-valid but possibly still broken one.
eg. the code can't do much when the parent key is wrong
I'm using the following snippet as test vector
it doesn't work properly for some reason (probably a thought error on my side)
on first run and into
with no empty key (i.e.
on first try. on another topic, on the initial config read, g_critical should stop irssi from starting up so you get a chance to fix your config. but this operation seems to happen after I already lowered the priority and the screen has been initialized, so the warning only blinks for a second before being replaced by the TUI
so maybe we should just revert to your initial suggestion :$