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

[enh]

On Sun, Mar 24, 2024 at 1:12 AM Rob Landley <rob at landley.net> wrote:

> On 3/22/24 10:26, enh wrote:
> > On Fri, Mar 22, 2024 at 8:24 AM enh <enh at google.com> wrote:
> >> (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.)
> >
> > (and to be clear, although "lsb" is particularly obscure, i think this
> > is the same problem busybox's organization has: why do i have to care
> > whether something is in coreutils or linux-utils or procps? how is
> > that relevant to me?
>
> There's a reason I didn't use that as an organizing method. Although I did
> try
> to map them at the end of the roadmap, and need to redo that analysis now
> since
> it's been a while...
>
> > the best answer i can think of is "because i want
> > to only use toybox/busybox to replace _that_ package", but i don't
> > think the _directory structure_ helps there, right? that hypothetical
> > person actually wants more metadata in the kconfig part of the comment
> > inside each file?)
>
> That's the theoretical use, yes. So distros (and system builders like
> gentoo,
> buildroot, yocto, etc) can annotate package alternatives so if you want to
> install busybox's tar instead of gnu tar your package management system
> could
> cope.


yeah, "equivalent package" might be another field to add to your kconfig
replacement --- then folks could configure toybox as "coreutils" or
"procps" or both or whatever.

(but, like i say, _i've_ never used this, and can't really imagine why i'd
not just want "all the things", so...)


> In practice, making something like dpkg handle that was near impossible,
> and buildroot only did it because the maintainer of busybox created
> buildroot. I
> tried to add toybox to buildroot years ago and...
>
> https://lists.buildroot.org/pipermail/buildroot/2014-September/409298.html
>
> People still try from time to time:
>
> https://lists.buildroot.org/pipermail/buildroot/2017-January/181960.html
> http://lists.busybox.net/pipermail/buildroot/2022-September/652474.html
>
> But even a build system that ALREADY lets you swap in/out buildroot vs gnu
> versions of packages accomplished that by hardwiring busybox support deep
> into
> its build system.
>
> Getting something like debian to do that on the fly is... it's not really
> designed for it.
>
> I can think of better ways to do it (and am studying debian's build system
> in my
> copious free time), but I've been busy with other things and most people
> aren't
> motivated to try...
>
> I note that I did it by hand back when creating aboriginal linux, which is
> what
> led me to maintaining busybox in the first place, ala:
>
> https://landley.net/aboriginal/old/
>
> > When the Firmware Linux project started, busybox applets like sed and
> sort
> > weren't powerful enough to handle the "./configure; make; make install"
> of
> > packages like binutils or gcc. Busybox was usable in an embedded router
> or
> > rescue floppy, but trying to get real work done with it revealed numerous
> > bugs and limitations.
> >
> > Busybox has now been fixed, and in Firmware Linux Busybox functions as an
> > effective replacement for bzip2, coreutils, e2fsprogs, file, findutils,
> gawk,
> > grep, inetutils, less, modutils, net-tools, patch, procps, sed, shadow,
> > sysklogd, sysvinit, tar, util-linux, and vim. (Eventually, it should be
> > capable of replacing bash and diffutils as well, but it's not there yet.)
>
> That's the old page from before I restarted the project and renamed it
> Aboriginal Linux (based on QEMU instead of User Mode Linux, ala
> https://landley.net/notes-2005.html#27-10-2005). Before that I was going
> though
> the Linux From Scratch package list and _disposing_ of gnu packages, one
> by one,
> as I got busybox to replace them.
>
> But "dpkg-query -S $(which $NAME)" is pretty easy to do the mapping
> yourself on
> debian...
>

(yeah, though i suspect anyone trying to do this hypothetical "swap package
$X for toybox" would want the _opposite_ mapping, from package name to all
the commands. and i don't know of a way to ask apt that question? other
than brute-forcing all of the executables in all of the directories in
$PATH, anyway.)


> Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20240325/86d9c682/attachment-0001.htm>