Hacker News Reader

The code that used to be perfectly portable still exists, fork it and keep using it.

But if you're asking for a project to be maintained, then it means you want maintainers to put more work to keep new code working on an old platform. Constraints of old/niche platforms cause extra work for developers when adding new features or improving security.

> 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.

> Then the portability issue will have been fixed once and for all

That’s just not true. These targets may make different assumptions about various low level things such as memory ordering, byte-width, behavior on overflow, etc. While C might be okay to defer to the architecture on these questions, Rust is more strict.

I personally think you’ll just end up with a bunch of broken binaries.

> What people complain about is that code that used to be perfectly portable

Literally the whole point of the article is that this assertion is bullshit. It was never perfectly portable. It merely happened to compile, and maybe work, and maybe actually was secure.

> Rust just needs to help get one of the several alternative Rust implementations based on gcc officially supports similar to gccgo.

Who is "Rust"? Why would they pour money and effort into this? Would the gcc community finally ignore rms' demands to make gcc as hostile as possible to implementing new front ends?

> Then the portability issue will have been fixed once and for all and Rust will be chosen even for code on obscure targets such as Elbrus 2000, Sunway or Tricore.

This does not solve the problem the author describes.

I think the point this article is making is that the portability was a sham and a mirage from the get go.

Yes, it might compile on an oddball architecture, but a lot of that would be the autotools build system and the C compiler fudging around important details that could easily leave you with something that kinda-sorta runs but is a wide open security flaw. Or that runs for a while and then breaks in ways nobody could have predicted because you aren't meant to try to run cryptographic software on something out of the museum of historical computing.

What if, instead of Rust, they adapted C99 or newer which is not supported on all obscure platforms. Should they be shamed for using the quality of life improvements that make it easier to maintain the project because someone used their project on an unexpected platform?

They can pin an older version and have it work.