Re: Re[2]: [PATCH v2] Huge performance boost for recursion (cp, du, find, ls, rm, mv)

"Roberto A. Foglietta via busybox" <[email protected]> Thu, 2 Apr 2026 14:20:27 +0200
Newsgroups gmane.linux.busybox
Message-ID <CAJGKYO7cbDdVV3xgb=8U5Cr+f-hGfHPHH3Tr2uYVHiN5uj+M9A@mail.gmail.com>
On Thu, 2 Apr 2026 at 13:19, Laurent Bercot <[email protected]> wrote:
>
>
> >Defensive coding about p != NULL is a good practice that shouldn't be
> >avoided unless a branch-analyzer is used as an automatism to grant p
> >!= NULL at every code change.
>
>   Or people could realize that a nullable pointer (indicating an option:
> either NULL or a reference to an object) and a non-nullable pointer
> (an unconditional reference to an object) are two different types, even
> if the C type system does not treat them as such; document their
> interfaces accordingly; and make sure the function contracts are
> respected. Using a nullable pointer where a non-nullable one is expected
> is a bug, and so is the opposite even though it won't cause a segfault.
>
>   Defensive programming is a sign of lack of control on the code.
> "I don't know what my input is at this point, so I'll add a check just
> in case." Not exactly inspiring trust.
>
>   It's just like input sanitization, which should only happen in the
> outer layers because *you should always know whether you're handling
> sanitized or unsanitized input*.
>
>   Defense in depth is good practice when you're operating a system that
> can be breached. Programming is different - it's not operating the
> system, it's designing it, and I'd rather not have my architect say
> "is it breachable here? I don't know, but who cares, we test for
> intrusions anyway".
>

I read your explanation Laurent, and it is the same explanation a
young teenager would have given of the sex if the teacher would have
asked for civil education. Theoretically, you are right but in
practice Assembler is down we still dig down. If you think that I am
wrong, ask INTEL about their BIOS and your "theoretic security" never
booted at all, whatever. With the Qualcomm modems, it isn't a
different thing.

Just a long message exchange to say, drop every one of your hopes
if you are hoping that I start a C++ fork of busybox or in rust or whatever.
It is fine in C, definitely. IMHO.

Best regards, R-