Hacker News Reader

Comment by jonathrg | Hacker News Reader

C codebases can often be updated with minor changes to compile with a C++ compiler, after which C++ features can be gradually introduced. Is the Linux kernel different in this regard?

View on HN

At this point, C and C++ are not compatible. Please stop with this "Oh, just compile C with a C++ compiler." That ship has sailed over twenty years ago with C99. One major difference is designated initializers, which works differently between C and C++ [1]. And C also allows structure literals in function calls:

    cgci = XCreateGC(
             display,
             window,
             GCForeground | GCBackground | GCFont,
             &(XGCValues) {
               .foreground = ccwhite,
               .background = ccblack,
               .font       = cfont->fid,
             }
           );

[1] C++ requires the fields to be initialized in order; C doesn't have this restriction.

Compound literals are especially pernicious[1] because GCC and (I think) clang support them in C++ mode, but they have expression lifetime like C++ temporary objects, not block lifetime as in C. That's a guaranteed recipe for dangling pointers and stack smashing/snooping.

[1] From a C++ is just a C superset perspective. In C compound literals are awesome.

    $ cd /usr/src/linux
    $ rg ' class;'
    vmlinux.h
    8541:struct class;
    13515:   long unsigned int class;
    16416: unsigned int class;
    16917: u8 class;
    17351: u8 class;

Yes, with minor changes. A few variables need to be renamed, a few cast need to be added. Some churn for sure on such big codebase, but doable nevertheless. GCC did it, other projects did it, I don't see why the kernel can't.

I think the obvious one is that the Linux kernel is no small little project, and any tree-wide change is highly non-trivial. The compressed current source release is 138 MB. A 2021/5.11 lines of code figure I found was 30.3 million.

It's not impossible, but the Linux kernel is quite a complex project.

Yes.

https://harmful.cat-v.org/software/c++/linus

Read the LWN comments.

From a moderate skim, I'm not seeing much in there that really addresses this beyond FUD and over-simplification.

Which, I mean... it's the Internet. That's kinda expected. But if there's something specific you're seeing, could you link to it? I'm curious as well what the "stick to C" crowd's reasons are. "C plus this one feature of C++" seems rather defensible at a glance (ignoring the social difficulty in choosing which feature), but I'm sure it's much more complicated than that in practice.

Even if a project can choose some specific feature(s) to switch to C++ for, it'd severely reduce the barrier for adding reliance on more features; why did feature X get a pass, but not this other one? And C++ has a lot of such potential features that are harmless and easy to justify at their best, but can become headaches when used more broadly, requiring everyone and everything to deal with them.

The social aspects are very large and it wouldn't surprise me at all if that was by far the main reason... but that's much less of an issue in a kernel-like context where there are already oodles of rules beyond "write valid C code". They can and do impose significant limitations on the languages they use, successfully, for decades. Seems like they'd be able to do that with C++ too.

There is a comment purporting to show a difference between compilation speeds in C and C++ which uses iostream for the C++ example, which completely misses the point. Sure C++ has a lot of warts, but in terms of compilation speed it should be completely reasonable to use a few simple template functions.

Yeah, that's the main thing I saw and it's just plain completely wrong. The fact that C++ can more easily bloat into large build times, and people frequently make larger-build-time projects in it, implies absolutely nothing about its behavior in replacing simple macros like max/min.

There's ample evidence that it'll build just a fast as C there, so it's not an issue in this context, and that both can build quickly with care. That's kinda the point of C++: you can write plain C code plus [this one thing] and you basically don't pay for the rest, and it generally achieves that.

They do not address the question at all. Please write an answer yourself.

The specific macro discussed in the article is using various GCC builtins to safely support mixed integer types; i.e. failing on unsafe type promotions or coercion, but otherwise working automagically. C++ std:min, by contrast, requires all the values to be the same type. AFAIU, to accomplish the same semantics in C++ would require either template metaprogramming, or doing something similar to what the current version is doing with macros and GCC builtins. A C++ solution might ultimately be cleaner, but I don't think there's anything in the standard C++ library that is a drop-in replacement.

Nor would it perform well during compilation, which is very well discussed in the thread. C++ compilation is slow, like the macro expansion of the C versions of min and max.

It’s all in the thread, I don’t know how GP missed it.

Reply on news.ycombinator.com