Obsolete C for you and me
Obsolete C for you and me
Posted Dec 9, 2023 12:04 UTC (Sat) by mb (subscriber, #50428)In reply to: Obsolete C for you and me by ballombe
Parent article: Modern C for Fedora (and the world)
That's not true. There are good reasons.
Posted Dec 9, 2023 13:40 UTC (Sat)
by pizza (subscriber, #46)
[Link] (30 responses)
that should be "not _enough_ good reasons"
This scenario is describing a very real problem that folks with existing codebases have to deal with.
Posted Dec 9, 2023 14:23 UTC (Sat)
by mb (subscriber, #50428)
[Link] (29 responses)
Can you name a project that
I think that projects only fall into three categories:
No "very real" problem for 1) and 2).
Posted Dec 9, 2023 15:10 UTC (Sat)
by makendo (guest, #168314)
[Link] (2 responses)
NetHack is known to use legacy function definitions as late as 2021: The next revision of C is deprecating legacy function definitions. The development branch has since switched to modern function definitions, but the switch wasn't backported to the 3.6.x releases and Gentoo maintainers have forced
Posted Dec 9, 2023 15:30 UTC (Sat)
by fw (subscriber, #26023)
[Link]
Posted Dec 10, 2023 18:50 UTC (Sun)
by NYKevin (subscriber, #129325)
[Link]
Posted Dec 9, 2023 16:10 UTC (Sat)
by pizza (subscriber, #46)
[Link] (23 responses)
I can't name something that uses these specific legacy C features, but I help maintain one project [1] that is extremely sensitive to the toolchain used [2], making bisecting quite challenging when you have to cross a toolchain boundary and the old toolchain can't even be compiled on more modern systems.
> 1) They are unmaintained since decades. No need to bisect.
You make the same mistake as so many others by equating "unmaintained" with "unused" -- Disabusing folks of this notion is the entire point of this article.
[1] Rockbox, replacement firmware for a wide variety of MP3 players. Currently supporting a couple dozen platforms representing four major CPU architectures. It runs bare-metal, under SDL, and as a native Linux application that has to run on both ancient and modern userspaces.
Posted Dec 9, 2023 16:26 UTC (Sat)
by mb (subscriber, #50428)
[Link] (22 responses)
No, I didn't say that.
Posted Dec 9, 2023 16:31 UTC (Sat)
by pizza (subscriber, #46)
[Link] (21 responses)
So you fix the failures in your tree so you can continue building it with modern toolchians, but when you need to go back and bisect *your own code*, this vendored code no longer builds, forcing you to have to backport those changes at each bisection step.
This sort of thing can be _very_ common.
Posted Dec 9, 2023 16:42 UTC (Sat)
by mb (subscriber, #50428)
[Link] (20 responses)
It's a ticking time bomb for so many more reasons to vendor or even only depend on unmaintained code.
Such old code will often blow up in your face when compiled with modern optimizing compilers. Regardless of the proposed changes from the article.
In fact, I would actually *prefer* the build breakage over a subtle "miscompilation" due to decades old code not playing with the rules of the C machine model or having implicit types and declarations.
Posted Dec 9, 2023 18:45 UTC (Sat)
by pizza (subscriber, #46)
[Link] (17 responses)
Why? It had been working just fine.
I'm using in production a bit of software that literally hasn't been updated in nearly three decades. Replacing it with anything else woulld require a nontrivial amount of effort, for no measurable gain.
(I had to do a little bit of work to make it compile on 64-bit targets but that's been the extent of its maintenance in the past 20 years)
Posted Dec 9, 2023 19:02 UTC (Sat)
by mb (subscriber, #50428)
[Link] (16 responses)
To avoid building up more and more technical debt and to prevent it from exploding.
>It had been working just fine.
Until it exploded the bomb was just fine.
Posted Dec 9, 2023 19:13 UTC (Sat)
by pizza (subscriber, #46)
[Link] (15 responses)
Are you volunteering to pay me to do this work?
Or is this just yet another example of someone demanding that I perform unpaid work on their behalf?
Posted Dec 9, 2023 19:43 UTC (Sat)
by mb (subscriber, #50428)
[Link] (14 responses)
Nope. It's your project.
> Or is this just yet another example of someone demanding that I perform unpaid work on their behalf?
No. Not at all. I am not demanding anything.
But please don't complain, if it explodes.
Posted Dec 9, 2023 22:56 UTC (Sat)
by pizza (subscriber, #46)
[Link] (13 responses)
What you call "piling up technical debt" everyone else calls "priorities"
> But please don't complain, if it explodes.
Um, I'm not. Once again, you presume something not in evidence.
None of this stuff "explodes" on its own. Indeed, it works just fine in the environments it's been used in for (as you put it) "decades". However, the article, and this discussion, is about how a _new_ environment has come along that causes (usually trivially-fixed) compilation failures on code that's not needed significant maintenance for "decades". How is that property not a _good_ thing? What is this modern fascination with constantly reinventing the wheel just to stay in place?
Posted Dec 10, 2023 0:59 UTC (Sun)
by marcH (subscriber, #57642)
[Link] (12 responses)
While that fascination is real, it's absolutely not what this article and discussion is about. You're angry and not listening.
Posted Dec 10, 2023 2:39 UTC (Sun)
by pizza (subscriber, #46)
[Link] (11 responses)
Seriously?
I'm being scolded 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. Instead, I should switch to something actively developed.
That presumes that there is (1) an alternative with the necessary functionality, and (2) the transition cost is low to nonexistent. It also over exaggerates the scope and effect of the actual problem (ie a compile-time problem that is, most of the time, pretty trivial to resolve).
I've also pointed out, multiple times, that this article shows that "not actively developed" does not mean "not actively used", and the right-now cost of incrementally fixing this old software is far less than replacing it entirely.
(Anectdotally, those calling for wholesale replacements/rewrites/etc or otherwise telling F/OSS authors/maintainers/distributors/users/etc what they "should" be doing never seem to be the ones doing the actual work or helping cover its cost. I won't apologize for calling out that abusive, entitled behaviour)
Posted Dec 10, 2023 5:17 UTC (Sun)
by marcH (subscriber, #57642)
[Link] (1 responses)
Posted Dec 10, 2023 15:43 UTC (Sun)
by pizza (subscriber, #46)
[Link]
....You injected yourself into the tail end of a sub-thread that was about just that.
(Meanwhile, I agree that the article _wasn't_ about that, a point I've repeatedly made)
Posted Dec 10, 2023 15:58 UTC (Sun)
by mb (subscriber, #50428)
[Link] (8 responses)
That's not true. It's your choice and I respect that choice.
>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.
>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.
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.
Posted Dec 10, 2023 18:03 UTC (Sun)
by pizza (subscriber, #46)
[Link] (6 responses)
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!
Posted Dec 10, 2023 18:45 UTC (Sun)
by mb (subscriber, #50428)
[Link] (1 responses)
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.
>Meanwhile, *every* computer I have Linux installed upon is running completely unmaintained firmware
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.
> What exactly is supposed to "explode" in this context?
If you try to recompile it with a modern compiler many things will happen.
Posted Dec 10, 2023 19:35 UTC (Sun)
by marcH (subscriber, #57642)
[Link]
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"
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.
Posted Dec 11, 2023 17:02 UTC (Mon)
by pizza (subscriber, #46)
[Link] (2 responses)
...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.
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.
Posted Dec 11, 2023 19:48 UTC (Mon)
by pizza (subscriber, #46)
[Link]
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.
Posted Dec 10, 2023 19:20 UTC (Sun)
by marcH (subscriber, #57642)
[Link]
Small digression sorry.
Posted Dec 9, 2023 18:52 UTC (Sat)
by ballombe (subscriber, #9523)
[Link] (1 responses)
Which miscompilation are you talking about?
Posted Dec 9, 2023 19:01 UTC (Sat)
by mb (subscriber, #50428)
[Link]
Well, I said what I was talking about:
>subtle "miscompilation" due to decades old code not playing with the rules of the C machine model or having implicit types and declarations.
Just try to compile a 30-40 year old C program. Chances are good that it just won't work.
Posted Dec 9, 2023 16:57 UTC (Sat)
by andresfreund (subscriber, #69562)
[Link]
Postgres used ~two instances of "Missing parameter types in function definitions" until somewhat recently. Mainly because it made the code look worse to replace them.
Posted Dec 9, 2023 17:37 UTC (Sat)
by ballombe (subscriber, #9523)
[Link]
Why ?
2) They are maintained and already build with -Wall so that these legacy problems don't exist.
False: -Wall does not prevent commits that generate a warning to be pushed to a GIT repository.
Beside, maintainers come and go and making the live of new maintainers miserable by pretending they are responsible for the state of the repository before they took over maintenance do not serve anyone purpose.
Most current C project have their own memory management system (if only to deal with out of memory) which will likely need to do conversion between pointers of different type. It is quite easy to miss a cast (especially when the rules for C++ and C are different).
Obsolete C for you and me
Obsolete C for you and me
- was under active development in the last 5 years so that to-be-bisected bugs have been introduced and
- uses these legacy C features?
1) They are unmaintained since decades. No need to bisect.
2) They are maintained and already build with -Wall so that these legacy problems don't exist.
3) A very small group of projects that have very poor code quality and are actively maintained.
3) should not be used anyway. The fix is to rewrite them.
Obsolete C for you and me
boolean
is_edible(obj)
register struct obj *obj;
{
/* ... */
}
-std=gnu89 as a result.
Those definitions were declared obsolescent in the second edition of the standard, in 1999. According to published drafts, the next revision of the standard will remove them from the language altogether. I don't know what compilers will do about it. C23 also introduces unnamed parameters. Curiously, the syntax is not ambiguous even for compilers which still support implicit Obsolete C for you and me
int, but it is a rather close call.
Obsolete C for you and me
Obsolete C for you and me
[2] To the point we supply our own that needs to be built from sources
Obsolete C for you and me
I said that if there are no changes then there is no need to bisect.
Obsolete C for you and me
Obsolete C for you and me
It should have been priority number one to get rid of it decades ago before it exploded.
Obsolete C for you and me
Obsolete C for you and me
Obsolete C for you and me
Obsolete C for you and me
Feel free to keep piling up as much technical debt as you like.
It's your decision.
Obsolete C for you and me
Obsolete C for you and me
Obsolete C for you and me
Obsolete C for you and me
Obsolete C for you and me
Obsolete C for you and me
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.
Environments change and perfectly good software becomes an ancient mess.
Feel free to keep depending on unmaintained software. That is your choice and I am fine with that.
Obsolete C for you and me
Obsolete C for you and me
> then nothing else possibly could.
But it's not at all "unmaintained", because if problems do come up, they will get fixed.
This is enforced by law.
>Does this mean I should just scrap the lot?
That is a completely different thing.
That is what this discussion is about.
Obsolete C for you and me
Obsolete C for you and me
Obsolete C for you and me
Obsolete C for you and me
Obsolete C for you and me
Obsolete C for you and me
Obsolete C for you and me
Assignment between different pointer types is about impossible for the compiler to get wrong the compiler, whether or not cast are used.
Obsolete C for you and me
Obsolete C for you and me
> - was under active development in the last 5 years so that to-be-bisected bugs have been introduced and
> - uses these legacy C features?
Obsolete C for you and me
Especially if the CI system only test the tip of branch, not all the intermediary commits.
In any large code large code base there will always be some small percentage of commit that generate warnings.