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

[Oliver Webb]

On Thursday, March 21st, 2024 at 22:45, Rob Landley <rob at landley.net> wrote:
> On 3/17/24 14:52, Oliver Webb wrote:

> > Also a problem if you want to switch Version Control systems or distribute tarballs without a .git/ directory.
> 
> I already DID switch version control systems (from mercurial to git), and I
> already distribute release tarballs. Why do you think these are new issues?

I... Never said that those were new issues? Ones that would happen if we were to hide these in a new
branch yes, but not new ones.

> > Same here, I can remember the posix commands.
> 
> Can you? I still have to check some from time to time, and the definition of
> whether "tar" is a posix command or not is outright eldrich bordering on quantum.

I can certainly remember them better then the LSB commands. Most of the time I can
remember if a command is in posix, which is what matters when trying to find it usually.

> Back in 2012, when the number of commands was growing fast and having one big
> directory of them all was getting a bit busy, the alternative of sorting them
> into directories was annotating them with tags, and THAT was a nightmare (of the
> "this command has three tags" variety). And also implied future pressure to
> extend the existing kconfig implementation to USE the tags, which would be worse.
> 
> Moving them into subdirectories, with each command in ONE directory, and a
> README explaining what the directory was for, with kconfig automatically
> displaying them in menus and using the first line of the README as the menu's
> title, seemed the least bad crowd control option at the time.

I did recognize that there was probably technical discussion behind this in 2012/2013
when they were moved. Asked about it later in the email too. Nice to know.

> Collapsing the directories together when the last command is
> promoted (or deleted) out of pending might make sense,

What would happen when a new command shows up and we need to evaluate it then?
Or glibc does a new release and yet another thing breaks we need to demote and
re-promote eventually?

> I also note I think I've figured out how to replace kconfig: I can just make a
> list that scrolls up and down with a highlighted entry you hit space on, handle
> help text, search, exit/save, resolve selects and depends and have "menus" be a
> label line with its contents nested two spaces further to the right.

[Some paragraphs bikeshedding about kconfig use to be here, may they rest in a text file
until we get around to doing the kconfig rewrite]

> > A possible solution is to...
> 
> ...
> 
> > Then again...
> 
> I need to stop checking email every time I sit down at my laptop, because
> bikeshedding can eat an endless amount of time and I've got other stuff to do.
> 
> For one thing, I promised to look at
> https://github.com/landley/toybox/issues/486 tonight.

Sorry for getting in the way of that, the technical discussion about it was
interesting enough to me to respond to. Recently found something to run off to
and do while still benefiting toybox, so I'll stop bikeshedding about stuff like this.

> P.S. I never mind people asking "what's the status of" or "why didn't you", and
> when people say they don't personally like stuff they can never actually be
> WRONG about that. But suggesting what I "should" do is... tiring.

I never thought about it in a "what should I make the maintainer do?" way, more in a
"what benefits the project and makes it more usable?" way, considering possible solutions
to issues. Sorry if it seems like I'm trying to order you around. I also stated in the
email that reorganizing commands would be unfeasible, I talked about a
possible way it could've been done "better", but I didn't say you should do anything.

-  Oliver Webb <aquahobbyist at proton.me>