Announcement

Collapse
No announcement yet.

A 2024 Discussion Whether To Convert The Linux Kernel From C To Modern C++

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Originally posted by ssokolow View Post

    C++ can't innovate in the direction Rust does because the innovations are
    this is incorrect, and c++ does it in a BETTER way than rust does. IT is much more flexible and less reliant on an underlying system that is unknown and less accessible to the average programmer.

    Comment


    • Originally posted by cj.wijtmans View Post

      this is incorrect, and c++ does it in a BETTER way than rust does. IT is much more flexible and less reliant on an underlying system that is unknown and less accessible to the average programmer.
      By that logic, C++ is inferior to assembly language because you need to explicitly typecast before it'll allow you to FADD two bit patterns representing integers as if they were bit patterns representing floating point.

      Rust's biggest strength is the degree to which the compiler can enforce invariants at compile time. Piling on more syntax to enable more code doesn't remove the existing syntax's receptiveness to being used in nonsensical or UB-inducing ways.

      I'm reminded of how std:ptional<T> is inferior to Option<T> because it lets you blindly dereference a null optional "for consistency"... then what's the point of having it in the first place? It's like not wearing a goalie mask "for consistency with tradition".

      Wake me when C++ compilers start having command-line options to enable a restricted subset of C++ analogous to what Rust does when you stick #![forbid(unsafe_code)] at the top of a module to turn use of the unsafe keyword into a compile-time error. (A very useful tool for ensuring that all the code that needs the strong auditing is abstracted away in a module maintained by the most senior coders, while the more junior ones work on code that can't cause UB unless there's a bug in the senior coders' code.)

      Comment


      • Originally posted by ssokolow View Post

        By that logic, C++ is inferior to assembly language because you need to explicitly typecast before it'll allow you to FADD two bit patterns representing integers as if they were bit patterns representing floating point.
        C++ IS inferior to assembly. But you have to make compromises between the computer and the human. Rust just aint it for me, C++ is getting better but still has mistakes and cleanups to do.

        Originally posted by ssokolow View Post
        Rust's biggest strength is the degree to which the compiler can enforce invariants at compile time. Piling on more syntax to enable more code doesn't remove the existing syntax's receptiveness to being used in nonsensical or UB-inducing ways.
        with c++ you can enforce whatever you want with metaprogramming like templates, concepts and whatnot. I fail to see the point.

        Originally posted by ssokolow View Post
        I'm reminded of how std:ptional<T> is inferior to Option<T> because it lets you blindly dereference a null optional "for consistency"... then what's the point of having it in the first place? It's like not wearing a goalie mask "for consistency with tradition".
        then make your own like boost does.

        Originally posted by ssokolow View Post
        Wake me when C++ compilers start having command-line options to enable a restricted subset of C++ analogous to what Rust does when you stick #![forbid(unsafe_code)] at the top of a module to turn use of the unsafe keyword into a compile-time error. (A very useful tool for ensuring that all the code that needs the strong auditing is abstracted away in a module maintained by the most senior coders, while the more junior ones work on code that can't cause UB unless there's a bug in the senior coders' code.)
        Honestly would not mind an unsafe keyword for C++. But C++ kind of already has it with extern "C", although thats mainly for symbols and not for code.

        Comment


        • Originally posted by cj.wijtmans View Post
          C++ IS inferior to assembly. But you have to make compromises between the computer and the human. Rust just aint it for me, C++ is getting better but still has mistakes and cleanups to do.
          It's clear we'll never see eye to eye on what inferior means. I align with Alex Gaynor's What science can tell us about C and C++'s security on this but, if you want a car metaphor, I'm tired of seeing drunk drivers killing people, only for people like you to talk about how your country is making it easier for convicted drunk drivers to choose to install breathalyzers in their cars, but keeping it mandatory that the breathalyzer can always be unplugged if the driver's judges it necessary to get stuff done.

          The problem is that it's been demonstrated again and again that humans working in groups can't write correct C++, no matter how skilled they are individually, because it's not feasible to keep track of the shifting state of the invariants in the codebase without the compiler being able to say "Whoa there! That doesn't make sense in the context of the code Bill committed yesterday!"

          Originally posted by cj.wijtmans View Post
          then make your own like boost does.
          No thanks. I find it more pleasant to work with "Then make your own (whole language), like Mozilla did (with Rust)."

          Originally posted by cj.wijtmans View Post
          Honestly would not mind an unsafe keyword for C++. But C++ kind of already has it with extern "C", although thats mainly for symbols and not for code.
          Rust also has extern "C". I'm talking about something that imposes more compile-time checks than non-extern C++.

          Comment


          • Originally posted by Weasel View Post
            Nope, that's not my code, don't change it and claim it is.

            I made it an external function for a reason. Put it in a separate file and tell me the output.

            A static analyzer in C can also catch this null dereference (and maybe does) since it can see everything in one file. Not specific to references.
            Just want to point out, this is the output if you put it into a "separate file" (Compiler Explorer, guckstdu hier):
            Code:
            Step build returned: 0
            [ 33%] Building CXX object CMakeFiles/the_executable.dir/io.cpp.o
            [ 66%] Building CXX object CMakeFiles/the_executable.dir/main.cpp.o
            [100%] Linking CXX executable the_executable
            [100%] Built target the_executable
            /app/io.cpp: In function 'func_byref':
            /app/io.cpp:11:6: warning: dereference of NULL 'a_2(D)' [CWE-476] [-Wanalyzer-null-dereference]
               11 |    a = 3;
                  |      ^
              'main': events 1-2
                |
                |/app/main.cpp:13:5:
                |   13 | int main()
                |      |     ^
                |      |     |
                |      |     (1) entry to 'main'
                |   14 | {
                |   15 |     another_func();
                |      |                 ~
                |      |                 |
                |      |                 (2) inlined call to 'another_func' from 'main'
                |
                +--> 'another_func': event 3
                       |
                       |   10 | func(nullptr);
                       |      |     ^
                       |      |     |
                       |      |     (3) inlined call to 'func' from 'another_func'
                       |
                       +--> 'func': event 4
                              |
                              |    5 | func_byref(*ptr);
                              |      |           ^
                              |      |           |
                              |      |           (4) calling 'func_byref' from 'main'
                              |
                       <------+
                       |
                     'func_byref': events 5-6
                       |
                       |/app/io.cpp:9:6:
                       |    9 | void func_byref(int& a)
                       |      |      ^
                       |      |      |
                       |      |      (5) entry to 'func_byref'
                       |   10 | {
                       |   11 |    a = 3;
                       |      |      ~
                       |      |      |
                       |      |      (6) dereference of NULL 'a_2(D)'
                       |​
            I dunno about you, but in my humble opinion it still looks like "compile time checking".

            Comment


            • Originally posted by darkonix View Post

              Did you read the link on https://www.phoronix.com/forums/foru...8#post1435008? It is not trivial for complex codebases like the Linux Kernel and probably most big older projects.
              I have read it now. Nobody said it was trivial. But as you see it is indeed possible.

              There are many ways to Rome. Globally replacing gcc with g++ is just one possibility. You could select C++ on a per-file base. That's the way how the rust project tries to move forward.

              Comment


              • Originally posted by lowflyer View Post

                You could select C++ on a per-file base. That's the way how the rust project tries to move forward.
                The current experimental Rust implementation in the kernel is about implementing new modules. Existing files in the core are not replaced.

                Comment


                • Originally posted by mb_q View Post
                  So they want C++, especially C++20 to make kernel macros easier to maintain? Then again Rust is a better idea since it has both better macros than C++ and many kernel DSL-alike uses can just be done with traits. And modern Rust is like 2 years older than C++20.
                  Sure, C++ is a best option to make some unholy mixture of code representing all the paradigms in the last 50 year history of imperative coding, hence making everybody "feel at home" at some point, but is it a good idea?
                  I wonder if you even read the post at all. Sure, go ahead and rewrite the whole kernel in Rust. The point is, C code compiles as C++ which makes it a reasonable drop-in for a lot of still pretty big improvements over all the black macro magic and dependence on gnu extensions in C.

                  Comment


                  • Originally posted by tuxifan View Post

                    I wonder if you even read the post at all. Sure, go ahead and rewrite the whole kernel in Rust. The point is, C code compiles as C++ which makes it a reasonable drop-in for a lot of still pretty big improvements over all the black macro magic and dependence on gnu extensions in C.
                    It doesn't just compile in complex codebases. You need to port it. Read the link in https://www.phoronix.com/forums/foru...77#post1436077.

                    Comment


                    • Originally posted by lowflyer View Post
                      This is much less likely to happen with the works of a real artist.

                      These engines are quick to create "a melange" of existing works. They don't "create" something really new. The "newness" is only in a new combination of existing works. However, human "input" or the "use" of the AI by a human can put the lacking creativity into it.
                      But not entirely. We're already seeing people on the autism spectrum struggling with discrimination from school-system bureaucrats who receive false positives from "students may not use A.I. to write their papers" detectors because our use of grammar and vocabulary has always been a bit "robotic" and checking for struggling with ex nihilo creativity is one of the ways they diagnose the associated executive dysfunction.

                      Likewise, if you use a LoRA that changes the art style away from the uncanny-valley photorealism A.I. art loves to something like that 1930s/40s/50s/TV80s Disney cartoon style (eg. DuckTales, Talespin, Rescue Rangers, Darkwing Duck, Goof Troop, etc.) or something suitably "generic anime" and make sure to inpaint the mistakes away, I already struggle with telling whether something is A.I. art or just another piece with the boring amateur-artist posing/composition that Stable Diffusion got over-trained on because insufficiently creative humans do it so much.

                      Comment

                      Working...
                      X