Why its still happening... would be interesting to know if its 40+ year old code or just screw ups. In the mid/late 80s I know people did this on purpose, accepting the risks in favor of performance, out of ignorance or desperation or whatever. I recall it being occasionally advocated during those years, by peers & professors here and there.
Isn't it more relevant the experience of the programmers rather than the age of the system? And as anyone can have an 'off day' (including me! - and I've used C++ since the early 1990's), we have very rigorous code review. Only reviewed code can be moved into 'production'.
Aren't these memory issues etc more due to both the 'quality' of the programmers used and the testing/review processes?
> Aren't these memory issues etc more due to both the 'quality' of the
> programmers used and the testing/review processes?
It is not trivial to review and clean all the legacy code in a huge code base which has evolved over a number of years and is still continually evolving. 'Stop all new enhancements till legacy code is completely rewritten' is not a feasible proposition in a fiercely competitive domain.
In any case, rigorous code reviews alone would not guarantee temporal safety in code where performance is an overriding design goal.
> I was referring more to when the code was written....
This kind of error need not be because of an obvious error in a piece of code as written by a single programmer. The code could have been robustly reviewed and found to be perfectly fine before it was committed. Much later, a change or addition to some other part of the code base, by another programmer, may violate the assumptions made by the original programmer about how that part of the code would be used. Now the code is broken, though when the code was originally written and reviewed, these assumptions appeared to be natural, sensible, reasonable.
Well hand-on-heart I've never knowingly issued production code with known bugs. I've issued code with missing features and code that later was found to have bugs but then all known ones were fixed before the next release.
Maybe I've been 'lucky' with the companies for which I've worked - as I've either worked for in-house development or for software houses that produced line-of-business software to spec (where the only competition was obtaining the contract in the first place). I've never worked in an environment/company that produced programs for public usage (and I'm not starting now as I'm now semi-retired!).
I personally won't gloat, much, about this vulnerability
And you shouldn't, it's quite a silly thing to gloat about. When you can't see the source code to something, or even when you can see it, and don't have control over it, there's really nothing you can do over it. You just gotta sit there and take it. That's what proprietary software is; you just have to sit there and watch what it does to your computer, and you have no say about it. (And that's if you even know about it; it could just be going on behind your back -- that doesn't mean the problems don't exist.)