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

[Rob Landley]

On 3/17/24 14:52, Oliver Webb wrote:
> On Thursday, March 14th, 2024 at 12:04, enh <enh at google.com> wrote:
>> at a high level, it does seem like many/most people interpret "pending" as "almost done" (he says, being part of the problem himself, having several pending things building and shipping on all Android devices) whereas in actual fact it can mean anything from "yeah, actually pretty much done" to "will be completely rewritten" via "still just trying random experiments trying to work out _how_ this should be rewritten".
>> sadly i don't have a better suggestion...
> 
> pending/experimental and pending/functional maybe, or something along that gist?

That would be my "not adding more complexity to manage transient clutter that
should instead go away" objection, already made.

> Then again it'd make it harder to track the history of pending commands, adding only new ones
> to those 2 directories would fix that, but would make the organizational problem for the old
> ones worse.

https://en.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering

Stop. No. Halt. Wait. Hold it. Woah. Cease. Desist. Caution severe tire damage.
Klatu barata nikto. Subcalifragilisticexpialidocious.

>> a branch would be the usual git option, but that would probably mean "no pending stuff in the main branch"
> 
> 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?

> It'd hide these commands too,

I want to close tabs. I am not creating additional scaffolding for clutter
management:

$ ls -d */toys
clean3/toys  clean8/toys     github/toys  kl4/toys  kl9/toys      toybox/toys
clean5/toys  clean.old/toys  kl10/toys    kl6/toys  kleen/toys
clean6/toys  clean/toys      kl2/toys     kl7/toys  kl/toys
clean7/toys  debian/toys     kl3/toys     kl8/toys  release/toys

I already try not to publish quite as much clutter as accumulates locally.

There's some real fossils checked into the tree. I started work on gene2fs back
under busybox, checked in what I had to the toybox repo in 055cfcbe5b05 in 2007
and haven't LOOKED at it this decade because I just haven't gotten back around
to it. Since then they INVENTED EXT4. (I still hope to get back to it, but at
the moment I'm answering email.)

> For the first time I checked if there were any special branches in the repo because
> I didn't bother to think about that in the months I spent working on it. 
> 
>> i still struggle between "other" and "lsb" in particular.
> 
> 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.

> But I don't care about LSB enough to
> memorize everything in wants. And keeping all completed commands that aren't in poisx,
> lsb, networking or android

The "example" directory is important because it's the only other directory of
commands that should not "default y" in defconfig. It has a policy distinction.

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.

> in a massive "other" folder sorta defeats
> the purpose of these directories which are supposed to reduce clutter.

It wasn't really about reducing clutter. I mean yeas, back then some web viewers
wouldn't display more than 250 files in a directory, the way github truncates at
1000 today:

https://github.com/landley/linux/tree/master/arch/arm/boot/dts

But the goal was annotating command categories. Posix and pending are obvious,
and I mentioned example. Back when I split them up, LSB was still a viable
standard (the Linux Foundation hadn't destroyed it yet), and it STILL kind of
means "this command existed back in Y2K and was considered part of the base
system back then, even if posix never caught up". Several commands in pending
get promoted into LSB (such as most of the password stuff, although oddly
mkpasswd is NOT in lsb 4.1).

Hmmm, possibly instead of a dead standard the linux foundation killed, I should
instead check the $PATH of my old red hat 9 install from the dawn of time...
Hah, it's still on busybox's website:
https://busybox.net/downloads/qemu/rh-9-shrike.img.bz2 Login as user busybox
password busybox, I believe the root password is also busybox. But that's
post-1.0, I'm not changing horses midstream...

Anyway, toys/android basically meant (to me), "commands that come from and are
maintained by Elliott which I can't even test because they don't apply to a
vanilla linux system that isn't running the full android environment". Although
that's a personally idiosyncratic definition because I lumped selinux in with
that; the only other environment I've noticed having a big selinux rule stack is
Red Hat. I haven't noticed a lot of selinux in debian, arch, gentoo, alpine,
buildroot... Even SuSE used apparmor instead, although they switched to selinux
recently because their business model is to be the Diet Red Hat so vendors have
a second source to solicit enterprise bids from, so there's business logic to
minimizing the delta between them regardless of technical merit (and spending
less maintaining parallel infrastructure just to sign things in triplicate).

I admit "toys/net" is a distinction that hasn't really worked out: I didn't even
put nbd_client.c and nbd_server.c in there. I could move all that into other I
suppose, if one less directory was worth making git log history less obvious...

And then everything that ISN'T in one of those groups needed a place to go,
hence "other". It's not ideal, but it was motivated by the number commands
continuing to increase and One Big Directory getting a bit busy, and needing a
place for "pending".

It's been the status quo for a dozen years now (commit 3a9241add947 in 2012) and
moving everything AGAIN would have costs, so I'd want a reason and assurance
that we're not going to change our minds again. Collapsing the directories
together when the last command is promoted (or deleted) out of pending might
make sense, figuring out what to do about example/ (trusting to the demo_ prefix
to annotate the example commands is nice, but hello.c hostid.c logpath.c and
skeleton.c would need... something).

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.

That's because I don't actually care about visibility the way they do (maybe
grey entries out but it just doesn't come up much), and my list doesn't nest as
deep as theirs so spacing off the right edge is less of a bother, and I don't
support modules...

But I need to close tabs to get there, and people keep sending me interrupts to
focus on instead.

>> `vi toys/foo.c` would save me a lot of thinking/calls to find.
> 
> Eh, keeping all the commands in a massive toys/ directory makes it harder to tell what we have.
>
> 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. (I did the code change
right after reading the commit, it's fluffing out the test suite to make sure I
know what it should be doing and that it's getting it right that's the headache;
"install -dm +x blah" applies the +x to 000 for some reason, and "umask 0;
install -d x" still does 755 so the behavior is NOT 777 minus umask...)

> In any event, a complete reorganization of the commands would make the history of them a lot
> harder to keep track of.

I believe I've said that every time this topic comes up.

Right, enough meetings about the lack of progress...

Rob

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.