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

[Oliver Webb]

On Sunday, March 24th, 2024 at 04:09, Rob Landley <rob at landley.net> wrote:
> On 3/24/24 01:00, Oliver Webb wrote:

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

There is a chicken and egg problem with the build infrastructure and kconfig being a toy,
We need a .config file to build toys, and parsing the help text requires some kconfig
parser, But we can't make a .config file until we have kconfig.

The solution I thought of was to use the infrastructure that we will have to have to remove
bash and gsed dependencies to build kconfig as a early step in the process.  But then we will
still need to extract the help text. Which implies we'd have to keep config2help.c, we'd have
2 seperate kconfig parsers, so maybe the solution is to build more upon config2help.c, we could
"#include toys.h" (Although that includes generated/config.h, so "#ifndef TOYBOX_BUILD" and -D
it in the CFLAGS for building this) and build with lib/*, Then again...

Do you plan on not keeping 2 different kconfig parsers or moving scripts/*.c to toys/example (We could
make toys/build tho, which would make slightly more sense), There's circular dependency nightmares
that would HAVE to be worked around at one point or another, a lot of stuff in the infrastructure relies
on kconfig so making kconfig rely on the infrastructure would require bootstrapping it in a weird way,
but there are also problems with that (main.c includes generated/*help.h files, toys.h includes generated/config.h),

So if the actual solution is to not make it a toy and build it with lib/* and toys.h to codeshare with lib/,
that creates problems too... Does any of lib/ depend on those functions in toys.h that live in main, grepping
through, of course there are parts, which means more ifdefs if we wanna pry it off the infrastructure, sigh.

-   Oliver Webb <aquahobbyist at proton.me>