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

[enh]

On Thu, Mar 21, 2024 at 8:45 PM Rob Landley <rob at landley.net> wrote:
>
> 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...

the BSDs have already done that experiment for us (with bin, sbin,
usr.bin, and usr.sbin [and contrib!] directories), and it's also a
PITA.

"if the new organization _still_ means i need to use find(1) for a
command that's default 'y', we haven't made things any better" :-)

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

(heh. you beat me to it :-) )

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

(tbh, just merging "lsb" into "other" would be a step forwards. wtf
is/was "lsb" anyway? and while i can _usually_ guess "POSIX or not?"
correctly, "lsb or other" is impossible by virtue of being
meaningless.)

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

for me the holy grail is "tab complete works and i don't have to think
about arbitrary partitions". i think "not yet default 'y'" is pretty
defensible (though the reason we're having this discussion is because
people _don't_ read "pending" as "danger, keep out!"), but the rest
seem so arbitrary.

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

no, i think example/ is defensible too. (i'd argue you're only ever
going to look in there if you have a _reason_ to. or you've done a
`grep -r` for something you're changing/checking all references to.
the reason i completely forgot about example/ is that it never causes
me the "where the fuck is _mount_?!" annoyance :-) )

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