[Toybox] [PATCH] toysh: fix -Wuse-after-free

[Rob Landley]

On 3/24/24 01:00, Oliver Webb wrote:
> I've done some research on this too, we have no "select" statements in any of our config symbols,

for a definition of "we" that is "I have intentionally not merged any", since I
review and approve all the kconfig command sections in the headers and have been
tracking that. (At one point the config2help.c stuff was trying to stitch
dependencies together to merge help text, and didn't understand complicated syntax.)

That said, forking the kconfig language definition is not something I do
lightly. Ours has fallen way behind the kernel's, and thus looks like something
else but is only compatible with a subset of it. We are about to _shrink_ that
subset. This needs a FAQ entry at least.

> but we do have a fair amount of that ""SYMBOL && (SYMBOL||SYMBOL)"" expression processing that's
> annoying to deal with.

I was referring to that, yes. I need to implement processing for it. I've
already implemented such processing in find, test, and twice in toysh (both
command && command and $((math&&math)) ).

> Also a "choice" block and a few number ranges in the main Config.in we will
> need to deal with in some way, the depends/selects stuff seems easy but with
> that expr evaluating probably isn't

Yes, I know.

> I tried to write a kconfig parser (As a toy to make the codesharing easier)

I've written at a bunch, and mostly thrown them away again. There's a simple one
in scripts/config2help.c and wrote one in python at
https://landley.net/hg/kdocs/file/tip/make/menuconfig2html.py which generated
https://landley.net/kdocs/menuconfig/ way back when. (Those are the only two
published ones that come to mind, but I've written more over the years.)

> and got absolutely nowhere. The approach I took to it was...

This isn't the hard part. To me, the hard part is wanting to share lib/*.c code
with this new binary, which implies it would live in toys/example/*.c, which
means in the NEW design it would be a normal command that's "default n"... and
maybe depends on TOYBOX_BUILD or some such? Except moving stuff from scripts/*.c
to toys/*.c is conceptually ugly. But if we're getting rid of the
subdirectories... Maybe make.sh needs to be able to build commands that DON'T
live in toys/ but then...

Unanswered design questions looming here, have not been jigsawed into an elegant
picture yet. (How much of that is assembling pieces and how much is SAWING THEM
UP I don't know yet...)

Anyway, it seems like config2help.c should also share this plumbing if it's
parsing the kconfig input anyway, which is convenient since I've been meaning to
rewrite all that too (and yes THAT has a motivating "somebody is waiting for me
to fix this", ala https://github.com/landley/toybox/issues/458 ), but there's
also the usage: line regularization
(https://landley.net/notes-2023.html#06-11-2023) and fixing the remaining
sub-options with maybe some sort of help text include syntax for inserting other
help texts at controllable points (as either blogged about or mentioned here on
the list, I'd have to check my notes to see where I left off on that)...

Once I've got the design worked out, coding it is usually the easy part.

Rob