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

[enh]

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

a branch would be the usual git option, but that would probably mean "no
pending stuff in the main branch", which would have been a net loss for
Android.

coming up with a clever name to distinguish the "keep out!" end of the
"pending" spectrum might prevent some of these arguments^Wdiscussions, but
i'm not sure and i don't know what that name should be... would even
something like "experimental" be enough of a warning? dunno.

anecdotally as an observer, it does seem like it is mostly just sh that
causes all the arguments ... _i've_ been happily ignoring toybox sh because
i'm fine with mksh for the time being (other than "can we have the bash
math exponentiation?" i think _every_ mksh bug i've ever had is "why isn't
the command-line editing better?", which isn't even a focus of toybox sh
anyway!), but it seems like everyone looking at toybox for some kind of
minimal distro wants to use the toybox sh. and those folks don't realize
that "pending" in this case really does mean "NOT A STEP" :-)

funnily enough, _personally_ i'd rather have _fewer_ directories --- toybox
is significantly less confusing than busybox was by virtue of having
significantly fewer directories, but i still struggle between "other" and
"lsb" in particular. `vi toys/foo.c` would save me a lot of thinking/calls
to find. (i've been trying to train myself to type `toys/*/foo.c` instead,
so far without much success. i usually only remember after i've _already_
done the find(1) :-) )

On Thu, Mar 14, 2024 at 9:22 AM Rob Landley <rob at landley.net> wrote:

> On 3/13/24 18:19, Oliver Webb wrote:
> >> If you want to complain, I do tend to have "s", "ss", and "sss" as an
> >
> > I did complain about that in the email.
>
> I noticed.
>
> >> You're basically complaining there was an "i" variable that wasn't a
> loop index.
> >
> > That IS a problem,
>
> Not "I have a problem", but "it IS a problem". Well it's good that you're
> here
> to define objective reality. Without such a universal arbiter we would all
> be
> lost a world of opinion and nuance.
>
> Me, I tend to have a gap between being able to tell "this isn't ideal" and
> knowing what ideal would look like. Yelling at me "this is a mess, clean
> it up,
> how top it NOW because I'm in charge of you!" doesn't really help the
> second part.
>
> > and when breaking/mixing the few conventions there are happens
> _constantly_,
> > with local variables that interact with each other. That becomes a much
> larger problem.
>
> "There are only two hard things in Computer Science: cache invalidation and
> naming things." -- Phil Karlton
>
> Do I need to tap the sign?
>
> > "i" is usually a counter used for at most a few dozen lines, "ss" and
> friends span regularly for
> > hundreds of lines.
>
> They didn't span hundreds of lines when I started writing the function. The
> function changed over time. The function is not finished yet. Gratuitous
> refactoring makes "git annotate" and friends useless.
>
> (I remember once when I was maintaining a tinycc fork, I introduced a
> subtle bug
> that took me days to track down by REINDENTING the code because I screwed
> up a
> curly bracket placement. I do not yet have what I consider a load bearing
> test
> suite for this command.)
>
> >> In multiple places, f stands for function, and there's more than one
> aspect to
> >> functions.
> >
> > I'm sure to someone who wrote 99% of it everything makes so much more
> sense.
>
> Tron: If you are a User, then everything you've done has been according to
> a plan.
>
> Kevin Flynn: Ha! You wish! Well, you know what it was like. You just keep
> doin'
> what it looks like what you're supposed to be doin', no matter how crazy
> it seems.
>
> > Just like
> > the people who maintain GCC and the coreutils and IOCCC entries.
>
> Carefully calculated to flatter me into agreeing with your opinions, I see.
>
> >> > The problem isn't the length as I said, the problem is that there is
> no convention for the naming
> >> > of these.
> >>
> >> Maybe I should move the file to "pending"?
> >
> > This is the most important command in the entire project (you can't _do
> anything_ on a machine without
> > a shell), No other pending command I've ever seen is this in-auditable,
> even ones written by you.
>
> "Even ones written by" me. How nice.
>
> >> And as I said: if I were to I apply an aesthetic patch which does
> nothing but
> >> make the code smell like you, toysh would be all yours and I would
> never touch
> >> it again.
> >
> > Make it look like whatever you want, I honestly couldn't care.
>
> Oh good, I can stop reading then.
>
> Rob
>
> P.S. Are you aware that you have opinions? That you're not an ordained
> judge of
> what is and is not correct? No, why should I ask questions: you didn't.
>
> To answer some questions you didn't ask: A _better_ name for a variable is
> not
> always immediately obvious to me as I'm writing. The uses of a given
> variable
> tend to change as the function develops. I tend to perform cleanup passes
> to
> make the code more intelligible AFTER it's otherwise working (and has a
> full
> regression test suite it passes so I can catch bugs introduced by
> refactoring).
> Things that are used a LOT tend to have short names in my code, because
> BigLongCamelCaseName repeated 400 times in a function does not make code
> easier
> for _me_ to manage or understand, and variable names get out of date the
> exact
> same way comments get out of date. Obviously, your experience differs, and
> I
> look forward to the shell you write from scratch that renders toysh
> unnecessary.
> It should be easy for you, given you can dictate empirical truth in a way
> that
> obviates judgement. Me, I'm muddling through as best I can...
> _______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20240314/b9230e04/attachment.htm>