> What people complain about is that code that used to be perfectly portable for years suddenly becomes locked to a very limited set of targets with the argument that memory safety is more important than anything else
As TFA points out, this is a mistaken understanding of the situation. What we have here is code that gave the illusion of being “perfectly portable” (while not actually being written to target or tested against the peculiarities of niche architectures like Itanium and PA-RISC it happened to successfully compile on) being replaced with a new version that only build on machines its authors have actually given any consideration to the security properties of.
That this inconveniences people is obvious. Why they imagine this is a net security loss for them is less obvious – the older C versions still exist, and any concerns that they’re missing out on new security updates are swamped out by the fact that the older versions may well never have behaved securely because nobody from the project was ever writing the code with PA-RISC’s memory and instruction ordering properties in mind to begin with.
As TFA points out, this is a mistaken understanding of the situation. What we have here is code that gave the illusion of being “perfectly portable” (while not actually being written to target or tested against the peculiarities of niche architectures like Itanium and PA-RISC it happened to successfully compile on) being replaced with a new version that only build on machines its authors have actually given any consideration to the security properties of.
That this inconveniences people is obvious. Why they imagine this is a net security loss for them is less obvious – the older C versions still exist, and any concerns that they’re missing out on new security updates are swamped out by the fact that the older versions may well never have behaved securely because nobody from the project was ever writing the code with PA-RISC’s memory and instruction ordering properties in mind to begin with.