Moving the kernel to modern C

I would not say they are fools. But they are somewhat hidebound - viz the use of email as their primary collaboration system. They are also as capable as the rest of us to have prejudices. C++ in the 1990s was not a good choice for a Kernel - the programming paradigms popular then, the quality of compilers then and the language features then were not there. We were also a lot less aware of the potential for security holes that C code was subject to without a careful eye. Things have changed. Knowledge has been acquired about the best approaches to things. It’s been over 20 years. But as evidenced by some comments on this article - attitudes change slowly. Linux is unusual in major software projects as being very much a product of one person’s idiosyncrasies. There is a certain groupthink that it is particularly susceptible too. Different ways of thinking have historically led to an unpleasant email.
I suppose what I am saying is that experience outside the Kernel community suggests that using a language which enables the us of low or zero cost abstractions and automates resource management is a good idea. Trying to emulate these features in C89 (using macros!) because C89 is all you have is not a good solution. Preserving with C because it’s what you know is also not the best for a project that is used as a bedrock of modern computing.
Kernel mode C++ standards exist. They’re quite reasonable and not hard to implement or learn.

[Caveat: haven't written lots of C++ in years, and that was back in the early '10s. The language has changed and I haven't kept up, I know...]

The thing ncm likely meant was that Wol's imagined kernel-developers' worries are not actually what they are documented as having worried about. C++ is not a security nightmare, not any more than C, anyway; it hasn't been worse than C optimization-wise for about twenty years; and there is no sudden extra need to drop into asm just because this is C++ (C++ is still nearly a superset of C, and this is just as true of the GNU variant).

Their stated worries are more that C++ has abstractions that enable things to magically happen behind your back with no immediate indication at the call site, and since the kernel developers are really looking for a portable assembler a lot of the time, where everything the machine does is obvious, this is *far* from what they want: they have their hands full coping with parallelism-induced complexities, memory model complexities, looking out for speculative execution gadgets etc etc, without worrying about the apparently same code doing wildly different things depending on what type they're operating on.

Many of C++'s transparently-do-things features are routinely used and almost essential to use anything resembling modern C++: references are the classic case (now function parameters' values can change in the caller without an & at the call site), but also C++ before std::move used to not make it terribly clear whether things were being copied or not (and it was at the very least wordy to enforce one alternative), and even now we have things like stringviews which seem to come with built-in footguns. (Of course, the kernel would never use such pieces, but code review would need to make sure they never crept in... and you only need to forget *once*). Many of the pieces that *don't* amount to 'do this invisibly albeit usually helpfully' are related to templates, and, uh... the kernel is nonswappable code in which size is at a premium, and having the compiler promiscuously generate code to monomorphize templates on the fly was anathema for a long time (though Rust does the same thing, and people seem to be complaining less: maybe RAM is just that much cheaper now and kernel code size is less important? but icache bloat still matters, and Linus has worried about it in public, and that was years ago and it's worse now).

And that's without even mentioning the really big painful problem, so big and painful that there are still compiler switches to disable the feature entirely, so big and painful that it took decades to figure out how to write code safely in the presence of these things and the last time I looked at it the safe code was extremely unobvious and if it was wrong you were unlikely to know for many years until things blew up, because there was no way to automatically check for safety: exceptions. Lovely idea, makes code's non-exceptional path much clearer, but the implementation explodes exceptional flow paths and *all of them are invisible* and many might be in what looks like the middle of an atomic, indivisible entity to someone not thinking "what if this were overloaded and threw?". If you use RTTI for absolutely everything religiously you don't need to worry, but you only have to forget and do manual cleanup once and you're in trouble when you next get an exception passing through that region. The kernel would obviously never use exceptions in the first place, mind you. Of course that now makes it impossible for destructors to fail, which probably rules out *use* of destructors for anything nontrivial, which means you can't use RTTI, which means you can't write anything resembling modern C++. You don't pay for what you don't use, but many of the bits require many of the other bits to use them non-clumsily, and then many of those bits are papering over design faults in the earlier bits -- std::move, again -- and the result of adding all those bits together is *ferociously* complex.

> The scope of the control variable declared in the for loop is the loop itself, so you can't declare another variable with the same name in the same scope.

What you say agrees with the C++ standard, but it makes me wonder why the standard authors appear to have been competing to come up with the most Byzantine special cases and exceptions they could think of to integrate into the standard rather than taking the simplest and least surprising route. Syntactically, the body of the for loop is a single statement which may be a compound statement. That part is the same as C. The braces are *not* part of the syntax for the loop. If the scope of the control variable were in fact the loop itself, and the body were treated the same as any other statement, then the compound statement would be an independent scope nested *within* that for-loop scope, and declarations within the compound statement would shadow any declarations scoped to the for loop (as they do in C). Instead the standard pierces the abstraction and treats compound statements in a for loop body differently than compound statements located elsewhere. There is no logic to this that I can see, just a bald statement that "If a name introduced in an init-statement or for-range-declaration is redeclared in the outermost block of the substatement, the program is ill-formed."

for (init-statement condition[opt] ; expression) statement

for (int i = 0; i < N; ++i)
    char i = 7;

for (int i = 0; i < N; ++i) {
    char i = 7;
}

{
    int i = 0;  /* init-statement */
    while (i < N  /* condition */) {
        { char i = 7; }  // statement
        ++i;
    }
}

Why would be the purpose of a declaration without an explicit type?

How would a typeless declaration help the people in this thread who complain about not finding declarations? If not the type, what else are they looking for?

> > That's exactly why I despise operator overloading. You cannot trust anymore what you're reading.

> It's certainly an extreme reaction for a relatively minor thing. In an object orientated language, if your function gets passed a object x of type t, if t can be inherited from, x.method can do anything, no matter what the code for t says.

Not knowing what code will run is considered a "relatively minor thing" only by fans of inheritance and object-oriented languages. Even in C where OO is super-explicit, tracking what .ops will run is one of the most time consuming thing.

"Object-oriented programming is an exceptionally bad idea which could only have originated in California." :-)

And of course the classic http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html

> The King, consulting with the Sun God on the matter, has at times threatened to banish entirely all Verbs from the Kingdom of Java. If this should ever to come to pass, the inhabitants would surely need at least one Verb to do all the chores, and the King, who possesses a rather cruel sense of humor, has indicated that his choice would be most assuredly be "execute".
> The Verb "execute", and its synonymous cousins "run", "start", "go", "justDoIt", "makeItSo", and the like, can perform the work of any other Verb by replacing it with an appropriate Executioner and a call to execute(). Need to wait? Waiter.execute(). Brush your teeth? ToothBrusher(myTeeth).go(). Take out the garbage? TrashDisposalPlanExecutor.doIt(). No Verb is safe; all can be replaced by a Noun on the run.

Agreed that the implicit promotions and convert rules in C is a bit complex (and actually it would be nice if there where a tool one could use to highlight an expression and have the tool explain exactly what happens in this regard) but they are at least specified in the standard.

For your example at hand with "a + b" where we have "int a" and "unsigned int b" and a have a negative value then since both are of the same rank (integers) but different types (signed vs unsigned) the signed integer is implicitly converted to an unsigned integer. Overflow is only undefined for the signed integer case while defined to wrap around for the unsigned integer which is why most of the "a + b" code works as intended.

Aka if a is -1 and b is 2 then -1 is "converted" to 0xFFFFFFFF, add +2 and we wrap around to 1. In practice the compiler simply moves both a register and does the x86 ADD instruction since converting signed to unsigned of the same size is a no op and a binary add in particular is signedness agnostic.