Linus Torvalds Prepares to Move the Linux Kernel to Modern C (zdnet.com) 114
"We all know Linux is written in C," writes ZDNet. "What you may not know is that it's written in a long-outdated C dialect: The 1989 version of the C language standard, C89."
But that's about to change, explains long-time Slashdot reader UnknowingFool: Linus Torvalds has decided that Linux will move to the C11 standard starting with kernel 5.18.... Linux had planned to move to a newer standard eventually with C99 being the next version. However a recent patch to a security problem revealed that there could be problems with C99.
In order to patch a potential security problem with Linux's linked-list primitive speculative-execution functions, it was found that C99 would require the iterator must be declared outside the loop which would expose it to another security problem. Since C99 was not very popular, it was agreed to skip it and use C11. Backwards compatibility with most compilers like gcc should allow for an easily transition of most of the code.
ZDNet adds that "This isn't as big a transition as it may seem. C89 still has almost universal support. Because any C compiler is backward compatible with earlier versions, you won't have any trouble compiling or running a C89 program. So, a C11 compliant compiler won't have any trouble with any C89 legacy code."
But that's about to change, explains long-time Slashdot reader UnknowingFool: Linus Torvalds has decided that Linux will move to the C11 standard starting with kernel 5.18.... Linux had planned to move to a newer standard eventually with C99 being the next version. However a recent patch to a security problem revealed that there could be problems with C99.
In order to patch a potential security problem with Linux's linked-list primitive speculative-execution functions, it was found that C99 would require the iterator must be declared outside the loop which would expose it to another security problem. Since C99 was not very popular, it was agreed to skip it and use C11. Backwards compatibility with most compilers like gcc should allow for an easily transition of most of the code.
ZDNet adds that "This isn't as big a transition as it may seem. C89 still has almost universal support. Because any C compiler is backward compatible with earlier versions, you won't have any trouble compiling or running a C89 program. So, a C11 compliant compiler won't have any trouble with any C89 legacy code."
So what are they moving? (Score:3)
Re: (Score:3)
That kind of typo, between C11 and C99, is precisely why such updates need to be done cautiously and with rigorous testing. A few typos like that, lost among thousands of lines of changes of things like indenting structures or subtle syntax shifts, are easily missed.
Re: (Score:2)
You invested in money laundering, and Big Daddy Puta Poutine threw a war down on your shit.
Surely it was a risk you knew you were taking when you chose the money-laundering trade, and you absolutely knew the Russians were the biggest money launderers.
FUD is, by definition, manufactured. Here, the economic fear is organic, the uncertainty is real, and the doubts are undeniable.
Re: (Score:2)
I'm guessing existing code will stay as-is
I normally use C11 and I've never had to make changes to legacy code. Sometimes there are slight adjustments to the headers, so that new and old work together.
Re: (Score:2)
Re:So what are they moving? (Score:5, Funny)
Yes "C1911" was clearly a reference to the Colt Model 1911. What's not clear, though, is what an automatic handgun has to do with the Linux kernel.
Re: (Score:1)
Yes "C1911" was clearly a reference to the Colt Model 1911. What's not clear, though, is what an automatic handgun has to do with the Linux kernel.
It runs Linux.
Re: So what are they moving? (Score:5, Informative)
The 1911 is not an automatic. Only one bullet fires per trigger pull.
Re: (Score:2)
The US government called it "automatic" through at least the Vietnam War era. But you are right: in modern parlance, it's only semi-automatic.
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
Again, I am only referring to "automatic" use alone, different meanings pistol or rifle. "Semiautomatic" and "fully automatic" have the same meaning pistol or rifle.
Re: (Score:1)
So you are historically ignorant about the gun and its .45 ACP ammo. Even ACP stands for Automatic Colt Pistol.
Automatic used to mean self-loading, so any semi-auto was auto 8D
Re: So what are they moving? (Score:4, Funny)
The 1911 is automatic. It self-loads a new cartridge on firing. What it is not is capable of fully automatic fire, which refers to a different concept of automatic.
Re: (Score:3)
It is essentially the same concept, though. Anything self loading can be made fully automatic with a minor modification.
Re: (Score:2)
If you need to shoot yourself in the foot rapidly, you'd have to move to C++-1911.
Re: (Score:2)
The 1911 is not an automatic. Only one bullet fires per trigger pull.
In the 1911's context "automatic" refers to reloading not firing.
Re: (Score:2)
C1911 critical to year of desktop linux (Score:2)
Yes "C1911" was clearly a reference to the Colt Model 1911.
I was hoping for CZ 1911 A1.
What's not clear, though, is what an automatic handgun has to do with the Linux kernel.
You have to recall the word "linux" has dual use. As both kernel and a complete operating system. The handgun's use would be with respect to the latter, to finally bring about the year of desktop linux.
Hasn't been a huge problem (Score:4, Informative)
It hasn't been a huge problem because the Linux kernel uses the GCC variant of C89, which has many of the advantages of C99 and C11 already. So there wasn't any serious reason to upgrade before.
Re: (Score:2)
On the compatability front, tried to make a bit of K&R C "go". Can't do it with a recent-ish gcc.
It might work if you use the flag "-std=gnu89" or "-std=c89". This was the default until fairly recently.
Ah Modern (Score:2)
So Modern means that you move away from a 33-year-old standard, consider and reject a 23-year-old standard, then settle on an 11-year-old standard.
Re: (Score:3)
In another couple of decades we might be able to use C++. Who Knows?
Re: Ah Modern (Score:3)
Not in the core kernel they wont. The C++ memory model relies heavily on the heap which is often unavailable in the kernel so new, delete, copy constructor assembler etc would need to be different for kernel code. Also implicit memory allocation and function calling in the kernel is a no no so out goes the STL. Also C++ name mangling makes its use in dynamic libraries awkward as anyone who has had to write one knows since it needs a C wrapper.
Re: (Score:2)
The C++ memory model relies heavily
It does not.
on the heap which is often unavailable in the kernel so new, delete, copy constructor assembler etc would need to be different for kernel code.
To a first approximation new and delete are the C++ analogues of malloc and free, and as such C++ relies on the heap as much as C does in that context. C++ runs just fine on an ATtiny with positively bytes of RAM and no heap.
Also implicit memory allocation
C++ doesn't have "implicit memory allocation" any more than C do
Re: Ah Modern (Score:2)
So C++ doesnt do hidden object creation and hence memory allocation during copies then? Really?
As for extern C, good luck using that with overloaded functions or duplicate functions in different namespace.
Re: (Score:2)
It's not required to.
C++ can do anything that C can, just as efficiently. It can also do a whole lot more.
Re: (Score:2)
Congrats on not understanding the differences between kernel and application development.
Re: (Score:2)
So C++ doesnt do hidden object creation and hence memory allocation during copies then?
No.
Really?
Yes, really. The reason is that C++ is not C.
In C if you saw the code:
struct funky_type a, b;
assign_funky_type(&a, &b);
you wouldn't complain about "hidden object creation and hence memory allocation". Well the way you write that in C++ is:
// ...
funky_type a, b;
a=b;
In C++, = means a call to a function called operator=. It is no more hidden than calling a C funct
Re: (Score:2)
C++ vector has some implicit allocation if the vector grows in size.
Re: (Score:2)
Sure, but it has a function called "reserve()" and a second parameter so that you can supply your own memory allocator if you want to.
You want to use alloca() with std::vector? Not a problem.
https://stackoverflow.com/ques... [stackoverflow.com]
Re: (Score:2)
C++ vector has some implicit allocation if the vector grows in size.
That's utter bullshit while being at a very pedantic level correct.
The claim is that C++ has "implicit" allocation, as compared to C. This is manifestly not the case. If you call a function in either language, it may allocate memory inside the function. C++ is no different from C in this regard. The one difference is that C++ has a number of syntactic elements for calling functions that C lacks.
A function allocating memory is not the same a
Re: (Score:2)
Embedded-C++ maybe. It's a different language. Ie, if you aren't allowed to have exceptions at all then you're stuck unable to be C++ standard compliant.
Re: (Score:2)
It's still far better than C.
Re: (Score:2)
"Embedded C++" was defined as a subset of C++ simply because compiler companies in the '90s were having trouble getting templates and exceptions to work. Once that crisis was over, it went away. The thing is, it happens to be a perfectly valid subset of C++ that is in fact useful for low-memory embedded programming. By avoiding templates (which literally compiles a fresh variant of each function for every combination of types it is invoked with, hello bloat), you end up closer to the old "C with classes" co
Re: (Score:2)
Using "new" generally requires an exception. Ie, "new" either succeeds, or it throws an exception, it cannot return a null pointer like earlier versions of C++ did. Though you can work around this by having a pool of constructed objects instead of a pool of memory, and you can use malloc if you need to and then construct the object into that, but after awhile it's just tedious and the templates get more and more complex as you pass in allocators and the like.
So you can do all this stuff in C++, it's must mo
Re: (Score:2)
The C++ memory model relies heavily on the heap
Sure, the STL does, but there is nothing inherent about C++ the language (other than the default new/delete) that requires the heap, not even templates. "But muh copy constructors!" If you're not using heap objects, those never use the heap, just like avoiding malloc/free in regular C. In (low-memory) embedded programming, you simply don't want to be using a heap. And yes, iostreams goes out the window along with the STL.
It's also possible to override what new does. I did something once where it was a cont
Re: (Score:2)
Re: (Score:2)
That was the original cfront implementation in the 80s, it's no longer true.
Re: (Score:2)
C++ is not "C Improved".
C++ is OOP that the preprocessor translates to C which is then compiled.
Did you know that C is translated to assembly language and then assembled?
You'd better write everything in assembler then to avoid that step.
Re: (Score:2)
Re: (Score:2)
Nope. C++ is unfit for a kernel.
Re: (Score:2)
Re: (Score:2)
Not only. To begin with, OO in a kernel is a pretty bad idea unless you do not mind losing lots and lots of performance. But the second problem is that C++ does OO really badly. Sure, it is possible to do it even worse (Java, e.g.).
Re: (Score:2)
So Modern means that you move away from a 33-year-old standard, consider and reject a 23-year-old standard, then settle on an 11-year-old standard.
Considering that the Newest standrad is C17, and how conservative the Kernel Peple are, I guess is a sane choice.
You may think that C17 is 6 years more modern, but the Kernel guys may see i as C11 having 6 more years of testing, and modern features too boot.
Re: (Score:2)
Re: (Score:2)
Remember Linux can be used on very old and varied computer systems, not just PCs. Some older hardware may not support it as their C compilers may not support C17. While gcc generally supports C17, I am not sure if it supports it for all hardware.
A while ago there was a microarchitecture purge on the linux kernel. That took care of the more obscure systems.
As for the old systems, I doubt those can run a 5.16 kernel, no matter if it is compiled on C89.
So, going forward, I guess it does not matter much.
I guess/hope going to C11 is a stopgap meassure to go to C17, and latter on, to C2x
Re: (Score:2)
Re: Ah Modern (Score:2)
In my experience, die hard C programmers refuse to use any language that can't compile on the PDP-11. At least, that is the main thing they hate about Rust. That, and they abhor strings that aren't null terminated, because they believe strings should be free to extend to the end of the universe if they want to, and adding a length value wastes precious memory.
Re: (Score:2)
Re: (Score:2)
C17 adds a lot of stuff, though. Most of the difference between C99 and C11 is the new types, and a few naughty things being clarified as undefined.
In my applications I use C11. As do most people who aren't using IDE defaults.
It isn't just kernel people, C in general there is the attitude, if you don't need it, don't use it.
Re: (Score:2)
Re: (Score:2)
More modern is not the same thing as better.
Re: (Score:2)
Conservatism actually makes sense when it comes to programming. If you're following fads, you're going to leave a maintenance nightmare behind you. Technologies with a long history and multiple implementations are much more likely to stick around than the current flavor-of-the-month. Languages with just a single implementation should terrify you.
Sticking with C89 makes a lot of sense. I hoping that they keep their use of C11 features to a minimum.
Modern C??? (Score:2)
Re: (Score:1)
That's even older than Papal PrimaC (PapaC for short).
Re: (Score:2)
I use the People's Front of C.
Re: (Score:2)
Terry Davis has passed, his work unfinished. He lead a troubled life, but did all he could to do great things. May he rest in peace.
Reading the comments (Score:2)
Re: (Score:2)
Your comment reminded me of how I’ve felt whenever I tried to read a PD James mystery. In her stories, for me the mystery wasn’t that someone got murdered - it was how more of the obnoxious, thoroughly unpleasant characters avoided getting murdered themselves.
Always seem to have 99 problems (Score:2)
Things that end in 99 often have problems [wikipedia.org]. Using C99 would might cause the loop to explode and break away from the code ... probably taking the iterator with it.
Re: (Score:2)
You can solve the problems by using OverActors.
Declaring variables inside loops, good practice? (Score:2)
I found this discussion on StackOverflow helpful to understand this issue and the working of C compilers better.
Declaring variables inside loops, good practice or bad practice? [stackoverflow.com]
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
For me, the basic reason is that it's safer in terms of keeping things in as small of a scope as possible, to prevent accidentally reusing them in bad ways, thus better for maintenance and safety.
Technically, it just adds an update of the stack frame pointer each time you enter the new scope. Looking at the thread, I see there are times when you really don't want to declare something inside the loop, such as object variables. Creating an object variable each time through the loop could have much constructi
Re: (Score:2)
I have no idea where you got the Spectre/Meltdown thing,
From reading the lwn post I linked to.
and you didn't even mention which way would be better.
Definitely with lubricant.
Re: (Score:2)
Re: (Score:2)
The issue is mentioned in that thread, but as it's not the subject of the thread, it's not obvious what you were referring to. Apparently "for (int i=0; ...) {...}" might declare i in the scope outside the for() loop, so you can't do it twice.
Apparently C99 can put i in the outside scope. I've always thought I was being C99 compliant when doing that, so probably it's only enforced in "strict" compliance mode, because it's stupid. This means a C99 compiler is allowed (if not required) to put i in the outsid
The question I have is (Score:1)
the question I have is, why not C17?
I stopped reading at the 'Modern C' (Score:1)
Re: (Score:2)
I must have missed the word "rewrite" in the summary or linked article. Could you point me to it so I can reread?
Re: (Score:2)
Re: What is "modern C" in this context? (Score:2)
That sounds like a good way to introduce bugs. If only there was a language that was structured in such a way that it could guarantee no undefined behavior in the code at compile time....
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
It adds some types, and deprecates some things that were only done in poorly-written code.
None of the old code has to be rewritten. If there is old code that uses custom types similar to the new types, then they can choose to update the code by deleting some lines and batch-renaming the types. Easy peasy.
The changes are very small.
Re: Only thing that matters is (Score:2)
Well they are using linked lists...
Re: Only thing that matters is (Score:3)
For those who don't know:
https://m.youtube.com/watch?v=... [youtube.com]
Yes, there isn't an xkcd for linked lists, but it's generally a bad idea to use it, much like goto
Re: (Score:2)
The whole "GOTO is evil and should be avoided" is just ignorant nonsense.
GOTO? Come one, everyone knows COMEFROM [wikipedia.org], as it provides not only much more flexibility but also provides intuitive mutithreading facilities out-of-the-box.
Re: (Score:3)
Goto should be avoided; which means it should be low on the list of tools to use from your toolbox. But it can be used, but it should be considered carefully when it is used. Avoiding goto has has never been a ironclad prohibition and taboo. I have seen code that tried to avoid goto in such a way that is was every bit as confusing as old style spaghetti code with gotos (of course, it could have been made more readable without goto with some judicious splitting of a function into smaller bits).
Some people
Re: (Score:3)
The problem with rules of thumb like this is that they give you an excuse to not think, and so many people don't.
For example, did you know that you use gotos all the time? Really. You spell them "break" and "continue". This highlights a limitation of structured programming as without them, such programs could become needlessly complex.
People forget that the actual problem we were trying to solve with structured programming, and the subsequent demonization of goto, was complex control flow. While freely
Re: (Score:2)
Goto is fine, and also the only way to do some things like common abort code.
Re: (Score:2)
What about break which avoids the need for goto and is compleeetey different?
#define goto_end_of_block break
Re: (Score:2)
Break only breaks from the current loop/switch. It can only ever go up one level.
You can construct a more complex sequence of breaks with a flag, but it's easier and clearer to just use goto.
Re: (Score:2)
Re: (Score:2)
Good point, those nested loops never feel clean but I use a flag variable ('found' or 'finished' etc.) to get out of them. Goto is anathema where I work and would get rejected in code review, plus it is not destructor safe in C++. Another funnily bad option is exceptions: throw (bool)finished;.
Re: (Score:2)
Linked lists are used everywhere I've ever been and seen, except for C++ where linked lists hidden by prepending a std:: prefix :-) But if you can't use lists, then presumably you can't use trees, and if you can't use trees, then what is std::map using internally?
No seriously. I know the application level people hate data structures, and treat the runtime libraries as mystical gifts from the heavens that shall not be questioned or inspected, but every single one of those libraries are using linked lists u
Re: (Score:2)
Give Linus Torvalds a link to Stroustrup explaining why you shouldn't use linked lists and he'll likely just respond with his own explanation on why you shouldn't use C++. I doubt he'd value his opinion all that much.
Re: (Score:2)
The kernel devs have been clear that in their view C++ brings too much complexity for too little value added in this particular problem domain (the kernel).
I tend to feel that way about C++ in general. There probably are a handful of problem domains where that level of complexity is worth it. But application development isn't one of them, and that's mostly what I've been doing for the past 30+ years. I might feel differently if I worked on systems software.
Re: (Score:1)
I can't tell you how much of my time is spent removing
try(){}
catch(){}
blocks where basically every possible exception is caught as soon as it it possibly thrown. This is just idiotic.
Email address without SMS verification (Score:1)
With that said, why not walk into a shop, buy a SIM card for pay as you go and use it with one of the many cheap phone models which support IMEI replacement as part of the system? Most of the cheapest phones sold primarily to developing markets (like India) have firmwares available to do this and it provides you with full anonymity, p