Obsolete C for you and me

Posted Dec 11, 2023 19:52 UTC (Mon) by pizza (subscriber, #46)
In reply to: Obsolete C for you and me by Cyberax
Parent article: Modern C for Fedora (and the world)

> So making it harder to compile is a feature, not a bug.

That's a good way to ensure your code never gets used by anyone other than yourself. And yourself too, I might add.

(In which case, why bother publicly publishing anything at all?)

Obsolete C for you and me

Posted Dec 11, 2023 19:58 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (8 responses)

> That's a good way to ensure your code never gets used by anyone other than yourself. And yourself too, I might add.

That's not such a bad outcome. Old and insecure code should not be used for new projects.

An analogy: I love our railroad park, I'm helping to restore an old steam engine. We are even planning to run it through on a public railroad some time next year. It's fun! But I for sure don't want these engines running nearby every day, they don't have any kind of emissions control, they have terrible efficiency, and they're just plain dangerous.

> (In which case, why bother publicly publishing anything at all?)

Mostly for historical/archival purposes.

Obsolete C for you and me

Posted Dec 11, 2023 20:04 UTC (Mon) by pizza (subscriber, #46) [Link] (7 responses)

> That's not such a bad outcome. Old and insecure code should not be used for new projects.

Newer == automatically better, got it.

Obsolete C for you and me

Posted Dec 11, 2023 20:36 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

Not quite automatically, but yes.

Like pretty much everything else in engineering. The old code might be more compact and less resource-intensive, but it will almost 100% be less safe and robust.

Obsolete C for you and me

Posted Dec 11, 2023 20:52 UTC (Mon) by pizza (subscriber, #46) [Link] (5 responses)

> Newer == automatically better, got it.

I'm sorry, that was snarky and not what I meant to convey.

There's plenty of "newer" software that's grossly insecure or otherwise lacking in some way versus something that's been around a while. It usually takes a while to stabilize something into a generally usable form.

Meanwhile. When lrzsz was first published, it wasn't "old obsolete software" that should not be used for new projects. It was brand-new software, intended to be used by contemporary users. Saying that it shouldn't have been published or made more difficult to compile as to discourage folks from using it rather defeats the entire point of releasing it to begin with. And where would any of the F/OSS world be if that attitude was the norm?

What should this magic memory-hole/de-publishing cutoff point be? Months? Years? Decades?

One can't know in advance how long something will be actively developed or maintained. One can't know in advance how diligent users/integrators will be in ensuring stuff is kept up-to-date [1]. Meanwhile, its degree of maintenance tells you very little about its overall quality or suitability for a given purpose.

[1] Well, I suppose history shows us that the answer is "barely to never". How many routers are deployed running old, vulnerable versions of dnsmasq? How many are still shipping with these long-since-fixed vulerabilities?

Obsolete C for you and me

Posted Dec 11, 2023 21:21 UTC (Mon) by mb (subscriber, #50428) [Link]

Whether something is old or new does not make a difference for quality, most of the time.
What makes a huge difference is whether it is maintained or not.
That protects against bit rot.

Obsolete C for you and me

Posted Dec 11, 2023 23:21 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

> Saying that it shouldn't have been published or made more difficult to compile as to discourage folks from using it rather defeats the entire point of releasing it to begin with. And where would any of the F/OSS world be if that attitude was the norm?

lzsz had been maintained, up until some point in the past. And for software that is being maintained, migrating to new toolchains every now and then is not a huge burden. So in a hypothetical world where we are still using modems, lzsz would be rewritten in hardened C (like ssh). But that's not what happened, at some point lzsz lost its users and was abandoned. So this example is a success story of full software lifecycle.

And that's why I'm fine with making lzsz more complicated to compile. It hasn't been maintained for two decades, and using it as-is in production in current conditions is bordering on irresponsible, so it has to be thoroughly audited and fixed anyway.

> Meanwhile, its degree of maintenance tells you very little about its overall quality or suitability for a given purpose.

Honestly? It usually does. Unless you're looking into an area that naturally disappeared.

Obsolete C for you and me

Posted Dec 12, 2023 9:42 UTC (Tue) by farnz (subscriber, #17727) [Link] (2 responses)

Your comment about old, vulnerable versions of dnsmasq skirts the edge of the underlying problem; we treat software as an undecaying asset that can be built again and again from the source code and forever treated as "perfect", when it's closer in behaviour to the plans for a building. Nobody sensible takes plans from 5 years ago and expects them to be built unchanged with today's tools, techniques and materials; there's a constant shifting of requirements that means that we change things on the fly.

For example, I had recent construction work done; the plans were under 12 months old at the point I handed them over to the builder who did the work, and yet several changes were needed as we went along because the plans made assumptions that no longer held - the specific fire resistant material that had been specified was no longer available, and had to be substituted, the assumptions about what they'd find when digging for foundations turned out to be wrong (so we could use a smaller foundation), the locations of utilities as documented turned out to be wrong (including some that would have affected our neighbours if our builders hadn't changed what they did to match reality instead of the plans), and the price of insulating materials had changed so that we were able to change the plans to get much better insulation for slightly more money.

And this is closer to the reality of software; the source code is the plans, and (unlike construction), the build is done by automation, which means that whenever the plans turn out to be outdated, they need updating to keep up with modern requirements; at least with construction, when the plans turn out to be outdated, the workers turning plans into a building are capable of changing the plan on-the-fly to reflect reality on the ground, whereas a compiler simply isn't capable of doing that.

Obsolete C for you and me

Posted Dec 12, 2023 21:22 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (1 responses)

> at least with construction, when the plans turn out to be outdated, the workers turning plans into a building are capable of changing the plan on-the-fly to reflect reality on the ground, whereas a compiler simply isn't capable of doing that.

Or, if you've been relying on UB, the compiler turns out to be extra-capable of "changing the plan on-the-fly". But this is also because compilers take the source code as gospel and its "reality" is just some abstract fantasy machine.

And compilers do communicate through warnings and diagnostics all the time, but we're all too willing to ignore them at times.

Obsolete C for you and me

Posted Dec 12, 2023 21:27 UTC (Tue) by farnz (subscriber, #17727) [Link]

Oh, the compiler can change the plan all right - it just can't do so to reflect the reality on the ground (since that requires intelligence spotting that the programmer "meant" this, but wrote that), but instead to reflect its understanding of what you wrote, even if that's not what you intended to write.