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

Rob Landley rob at landley.net
Thu Mar 14 09:29:00 PDT 2024


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


More information about the Toybox mailing list