Interesting. But (I'm not an expert though) it might be that one cannot mothball those things for very long - you pump it or you lose it.

Additionally, even if it does not work for already producing assets, it as sure as hell will clamp down on new investments. And, maybe, that is just good enough of an outcome.

Interesting, how many times Saudis will have to spank new drillers so nobody will risk to make large investments into new wells any more. Unless some government intervenes with some kind of minimal price guarantee or something.

No, you simply didn't get the point. Google can't push the patch to those devices (unless they are from Nexus line). Samsung, LG, etc. must do the pushing. But they wont.

You are wrong. They don't want electric vehicles. And that simply because there is no money (or much, much less) in post sale maintenance.

That was my point - this way you eat only one recursive call, not two. And in general case (or naive qsort implementation) one recursive call is enough to burn (on bad input) through all your allowed stack.

Interesting. But just as a side note: I thought that people generally stopped rolling their own linear algebra code and started to use precanned one from Intel,amd,nVidia etc. I'm sure matlab is that way.

On stack size issue - the point was about a case of malicious/pathological input.

Yes, but they are clever about what and when they put on that stack. In their case it's indeed no more than log base 2 frames (non overlapping intervals with biggest one larger than the rest combined with the "rest" following the same pattern)

Sure, but that would also mean that debug compiled code, optimized code, ported code - all would behave too differently. Which, again, not a sound engineering practice.

I would guess that that "custom stack" lives in the heap, so in that case the limitation on program's stack size does not apply.

Very deterministic. Thus, easy to screw with. Just populate sample points with that worst case pivot value and voilà. Well... it needs to be done for all consecutive rounds so it's not completely trivial but doable.

If the algorithm is made very unlucky with selection of the pivot, then it will need one stack frame per each 2 data elements. So yeah, I think it's doable (if pivot selection is stupid in some predictable way)

WTF?! We're talking about general recursion, not some stupid, easily avoidable cases. Even in the case of qsort - you need to make 2 (not one) recursive calls one for left and one for right, and you need to keep the midpoint somewhere on the stack... Basically it's easier to roll your own, totally heap based accounting than try to be clever with stack frames. Plus GP explicitly said that there is recursion and your c compiler does not do tail recursion anyway (or you can't count on it)

Recursion makes for elegant code, but in production code should be avoided. At least when you have no control of the input data. The reason is that there is a fairly tight restriction on stack size (you have to explicitly tell your OS that you need large stack). As a result you will coredump if your input is the right kind of nasty.

At least with ECC you'll get _some_ feedback (it's random so it will pop from time to time) indicating that something fishy is going on. With regular ram all corruptions are silent so you'll get random crashes that will drive you crazy...