This has gotta be the most bullshit justification for writing bad kernel code that will be reviewed and tested by 200 people before it reaches production. Literally any line of code that's as low level has an incredibly large chance of error.

Old code in BSD wasn't thoroughly tested except by virtue of being old; there's no QA department and traditionally UNIX code was tested by thinking about it really hard rather than automated testing.

(FreeBSD got a test suite in 10.1, which came out in 2014, not that long ago in UNIX terms.)

Not just in BSD... GNU wasn't much better.

People would be shocked by how little the core tools we use were tested automatically. Some still aren't.

Quite.

Thankfully the practice of just randomly shelling out to 'random' programs (like the core tools) has been stemmed somewhat, so perhaps we're mostly safe from RCE via that vector. Downloaded files might still be a vector, tho. Maybe I'm an optimist even though I sound very pessimistic.

If your testing infrastructure is so anemic that a sorting algorithm (of all things) is hard to subject to e.g. property-based/fuzzing tests then it'd probably be worth it to expand that before doing anything else.

I dunno what FreeBSD's test infrastructure is, but I'm just saying that "it needs testing" is not a good reason not to change to a better sort algorithm in this case.

if only the people working on bsd in 01993 had had access to your wisdom, think how much more successful they would have been

This is about changing the sorting algoritm. No snark needed. It should be trivial to add a test for the current algorithm (whenever it was introduced) and to replace it afterwards. Heck, even keep running both for bisimulation testing.

probably colin was more interested in booting faster than in improving testing infrastructure

if your interests run the other way, that's great, and hopefully you will succeed in improving freebsd's testing infrastructure, but it's hardly a reason for colin not to speed up booting

but i don't think i saw anyone claiming that the change should not be made because it wouldn't be adequately tested?

I don't think you fully read the post I was replying to. I was just saying that that poster's argument against changing the sorting algorithm was misguided.

Quote:

> will be reviewed and tested by 200 people before it reaches production

I was only saying that this is a bad argument for any simple-ish sorting algorithm.

(Granted, if you're doing super-complicated sorting algos with fallbacks for different sizes, heurestics for detecting semi-sorted input, etc. you might want something more sophisticated than trivial property-based checking.)

i read that as an argument against having done it that way 30 years ago, not against changing it

No worries!

have you ever been bitten by typing a year in a C/C++ program and getting it inadvertently converted to octal?

heh

i'm not sure; i made a few mistakes in each of them as i was writing them, but they were both working by the time i first tested them. i do feel like the insertion sort was maybe a little more challenging?

edited to add: someonefromca spotted a bug in the insertion sort; where it says

    if (tmp > a[j-1]) break;

it should say

    if (tmp >= a[j-1]) break;

which is both a performance bug and also breaks the stability property the algorithm otherwise has

fwiw that comparison was where I went "wait, is that right?" in my reading.

Maybe a fair judge of mental difficulty would say "you gotta write at least the loop invariant" (termination being too pedantically obvious) -- though admittedly I leave it out more than I used to.

When I was introduced to sorting as a new programmer, via bubblesort, I thought "why that way?" and came up with selection sort as a method that made more obvious sense. It seems to me like bubblesort's alleged intuitiveness is post hoc from the shortness of the code in terms of all-ascending for-next loops -- the intuitive reason it worked was just that the inner loop did move the next max into place just like selection sort, but with extra swaps along the way.

You should edit the code in your original comment, someone is bound to copy paste the code somewhere…

it's only editable for two hours, for better or worse