Obsolete C for you and me

Posted Dec 10, 2023 15:58 UTC (Sun) by mb (subscriber, #50428)
In reply to: Obsolete C for you and me by pizza
Parent article: Modern C for Fedora (and the world)

>I'm being scolded

That's not true. It's your choice and I respect that choice.
But you have to live with the consequences of your own decisions.
It was your decision to use C features that have been deprecated and throwing warnings for decades.

>for using ancient software that does exactly what I need it to do, solely because it's just a matter of time >before it "explodes" causing me all manners of problems.

Yes. It's called bit-rot.
Environments change and perfectly good software becomes an ancient mess.

>Instead, I should switch to something actively developed.

That is *one* of the possible options that have been pointed out here.

>"not actively developed" does not mean "not actively used"

Yes. But nobody claimed that it would mean that.

>telling F/OSS authors/maintainers/distributors/users/etc what they "should" be doing

Nobody is telling you what you should do. That's a misinterpretation on your side.
Feel free to keep depending on unmaintained software. That is your choice and I am fine with that.

But I'm not fine with it, if you want to prevent certain developments of the C language itself, just to keep your ancient and trivially fixable code working.

Obsolete C for you and me

Posted Dec 10, 2023 18:03 UTC (Sun) by pizza (subscriber, #46) [Link] (6 responses)

> Feel free to keep depending on unmaintained software. That is your choice and I am fine with that.

I'm willing to bet that, on a daily basis, you trust your physical safety (if not your life) to "unmaintained software".

For example, the _newer_ of my two vehicles was manufactured 22 years ago. Any support/warranty/part supply/recall obligations its manufacturer had completely ceased seven years ago. If the software running in its ECU, ABS, and safety/airbag modules doesn't qualify as "unmaintained" then nothing else possibly could.

Meanwhile, *every* computer I have Linux installed upon is running completely unmaintained firmware -- The newest one fell out of support about a year ago. Does this mean I should just scrap the lot?

My point? "unmaintained" doesn't mean that it's automatically bad, untrustable, or incapable of fulfilling its purpose. Secondly, "maintained" in of itself tells you very little. Indeed, the Fedora folks' efforts with these old packages is itself a form of maintenance!

Going back a few posts, the "unmaintained production" software I mentioned earlier that you chided me for relying upon? It's a glorified data logger in a closed environment. It's been in production for approximately two decades, and it's "unmaintained" because *it hasn't needed any maintenance* in the past three years. It does what's needed, so what is to be gained by messing with it? What exactly is supposed to "explode" in this context? This particular bit of ancient software is actually the most reliable portion of the entire system!

Obsolete C for you and me

Posted Dec 10, 2023 18:45 UTC (Sun) by mb (subscriber, #50428) [Link] (1 responses)

> If the software running in its ECU, ABS, and safety/airbag modules doesn't qualify as "unmaintained"
> then nothing else possibly could.

Well, yes. I know. In my day job I write this software.

Probably the majority of the software in such a thing is "frozen". It will not be developed any further to add new features.
But it's not at all "unmaintained", because if problems do come up, they will get fixed.
This is enforced by law.

>Meanwhile, *every* computer I have Linux installed upon is running completely unmaintained firmware
>Does this mean I should just scrap the lot?

Nope. You completely missed my point again.

I am not at all talking about binary firmware sitting in devices. It's completely fine to keep using the same binary firmware for an infinite amount of time. It will not become worse with time.

I am talking about the legacy source code that is used in new compilations with modern compilers today.
That is a completely different thing.

> What exactly is supposed to "explode" in this context?

If you try to recompile it with a modern compiler many things will happen.
That is what this discussion is about.

Obsolete C for you and me

Posted Dec 10, 2023 19:35 UTC (Sun) by marcH (subscriber, #57642) [Link]

> ... binary firmware sitting in devices. It's completely fine to keep using the same binary firmware for an infinite amount of time. It will not become worse with time.

Only if it's really "airtight" (cause new attack techniques appear constantly) and use cases never ever change.

Even in such a case the company will likely want to re-use and evolve that source in some newer product. Then as you wrote, the binary is fine but the source is not.

"Zero maintenance" software can exist for sure but in many cases people who wish they don't have to pay for maintenance are just burying their head in the sand not to see technical debt.

Software maintenance has absolutely nothing to do with the fascination for shiny new things. It's actually the exact opposite. Confusing the two is not far from insulting the people performing ungrateful maintenance work. Unlike pseudo-"inventors"[*], they're never in the spotlight. Kudos to LWN for this article.

[*] search the Internet for "myth of the lone inventor"

Obsolete C for you and me

Posted Dec 11, 2023 10:51 UTC (Mon) by farnz (subscriber, #17727) [Link] (3 responses)

A twenty-year old binary built with Diab 5.0 either works or it doesn't; that's not going to change just because GCC 13.2 has a more thorough understanding of the C standard than GCC 3.1 (roughly contemporary to Diab 5.0). If you rebuild from the same sources today with Diab 5.0, you'll still get a working binary - nothing has changed, so nothing new fails.

Further, you can do your changes (if any are needed) with Diab 5.0 as the compiler, and it will interpret the code the same way it did 20 years ago. What you face trouble with is code that assumed that some underspecified behaviour would always be implemented the way the compiler of the day implemented it, and even then, only if you change the compiler. If you don't change the binary, it doesn't matter; if you change the source, but reuse the same compiler, it's (usually) fine.

The problem comes in when you change two things at once; both the compiler in use (maybe even as small a change as switching from PowerPC 440 to Arm Cortex-M7 backend in the same compiler binary) and the source code. At that point, you have the risk of a problem that could be anywhere, since most languages don't (arguably can't) tell you if the behaviour of the compiler has changed in a way the last programmer to touch the code would be surprised by. This applies to Rust, too; for example, integer overflow is underspecified in Rust by this standard (two possible outcomes, panic or 2s complement wrapping), and if the last programmer to touch the code didn't think about this, then you have room for a problem where only panic is acceptable behaviour, but instead you get silent wrapping.

Obsolete C for you and me

Posted Dec 11, 2023 17:02 UTC (Mon) by pizza (subscriber, #46) [Link] (2 responses)

> The problem comes in when you change two things at once; both the compiler in use (maybe even as small a change as switching from PowerPC 440 to Arm Cortex-M7 backend in the same compiler binary) and the source code. At that point, you have the risk of a problem that could be anywhere

...I'd argue a switch from a (usually) BE CPU to a (nearly always) LE CPU is a pretty significant change, to say nothing of subtleties like the memory ordering model and how unaligned accesses are handled.

But yes, change out a major portion of the compile or runtime environment (and/or other fundamental requirements) and the code may need updating. Change multiple things at once... you're likely in for a world of pain.

Obsolete C for you and me

Posted Dec 11, 2023 17:33 UTC (Mon) by farnz (subscriber, #17727) [Link] (1 responses)

But then we come back round to the beginning - why are you rebuilding code with a new compiler if no requirements have changed, and expecting it to behave exactly as it did when built with the old compiler? This goes double if your code depends on specifics of how the old compiler interpreted the code, rather than being code whose meaning is unambiguous.

And that, of course, leads to the big problem with legacy code - much of it (in all languages) is written "knowing" that if it passes tests when built with a single compiler, then it's good enough. But change anything (compiler, inputs, other bits and pieces), and it stops working.

Obsolete C for you and me

Posted Dec 11, 2023 19:48 UTC (Mon) by pizza (subscriber, #46) [Link]

> But then we come back round to the beginning - why are you rebuilding code with a new compiler if no requirements have changed, and expecting it to behave exactly as it did when built with the old compiler?

Well, if nothing changes, then.. you don't need to do anything. (That was kinda my point with respect to my using "unmaintained" software in a production environment)

But more typically, requirements do change... eventually. You rarely know what those will be in advance, or what effort will be needed to handle it.

Obsolete C for you and me

Posted Dec 10, 2023 19:20 UTC (Sun) by marcH (subscriber, #57642) [Link]

To be pedantic: "bit-rot" can happen even inside the same repo. It's not unusual to have some unused part of the code not even compiled on a regular basis. Then someone wants to resurrect it or to just increase coverage and surprise: it's not compatible with the rest anymore!

Small digression sorry.