Announcement

Collapse
No announcement yet.

KWinFT Going Through Code Refactoring, Working On WLROOTS-Based Usage

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

  • #41
    I am happy that this project is underway, but I do not like to read controversy every time. Also because a user to get an idea should also have the versions of the Kwin maintainers. In life I have learned that you must always listen to both sides in order to form an opinion. These controversies that punctually arrive at each post, do him no honor.

    Comment


    • #42
      Originally posted by polarathene View Post

      Going to take a guess that you mixed these two up? kdisplay is the one from KWinFT project, not kscreen which is older.



      I assume that's on X11 not Wayland?
      You're right, I meant to say kdisplay was better over kscreen. Similar names. And yes, X11, not Wayland.

      Comment


      • #43
        Originally posted by Steffo View Post
        C++ is backward compatible and if KWinFT uses C++ 20 and Mir C++ 17, there should be no problem. A library author usually knows about compatibility issues and is cautious regarding raising the requirements.
        No this ignores C++ standard library defects. There can be reason why you are not using particular features.

        Originally posted by Steffo View Post
        It doesn't provide 100% protection, but it makes it less probable than with C.
        You just ignore concepts like RAI and smartpointers which are far superior than goto.
        https://stackoverflow.com/questions/...smart-pointers

        Sorry to say its not less probable than C. I have not ingored RAI and Smartpointers at all. There are ways you use those that cause object leaks.

        Originally posted by mdedetrich View Post
        This is false, if you modern C++ features then you will have less use after free errors compared to C. Of course you can't completely eliminate such errors, but the occurrence is going to be a lot less frequent. Saying otherwise is misleading.
        The horrible part here that is not true.
        https://googleprojectzero.blogspot.c...aping.html?m=1
        Turns out the very features in modern C++ that are meant to prevent use after free can in fact create them. We have real world exploit examples these days. The horrible reality is items like smart pointers were built on the foundation of C that results in them being like quick sand as in looks solid when its not.

        The nightmare here is using C++ modern features a user after free error is normally harder to find. Why harder you have the stdc++ having its own allocator that may or may not be hookable for monitoring for leaks. C is missing the language features to make use after free less but its more compatible with tooling to find them. Yes the tooling added to modern C compilers are more likely to find use after free errors than modern C++ errors.

        The result is a interesting one. There are two percentages here the number of errors programmer makes and the percentage that the compilers detect. C the programmer is likely to code up more use after free errors and the modern compiler c is more likely to error over them result in build errors so end up fixed. C++ the programmer is likely to make less use after free errors in the code but the ones they make the compiler and runtime tools are less likely to detect. The result in final production software of C++ is more likely to be faulty than C with a use after free error.

        There is one feature that totally explains the change "AddressSanitizer" yes this is a feature that google added that has come standard in the common compilers these days. Its really good at pulling out C issues with use after free but its not equal as good at pulling out C++ smartpointer leaks or c++ object leaks resulting in use after free. So C++ modern features have the problem there is lack of tooling in compilers to detect when they have been used wrong this results in flipping the outcome of the final product. Lower detectability makes the modern C++ problems in fact more problematic not less due to being harder to detect.

        mdedetrich is really simple to miss the number of use after free errors in C code bases have dropped and it directly linked to change in the common compilers. This does show the importance of tooling to find defects as well as language features.

        Comment


        • #44
          Originally posted by curfew View Post
          Kwinft is developed for KDE so obviously it will maintain compatibility with KDE forever.
          It's designed to be a compositor that works with more than just Plasma, and the README is clear that there is no promises that it will keep parity with kwin over time.

          Activities is already dropped (while kwin recently added Wayland support for it), but there is discussions of a feature for "virtual monitors" similar to virtual desktops but not fixed to a specific display or virtual desktop.

          Originally posted by curfew View Post
          The problem here will be can the sole developer of Kwinft keep up with the upstream in terms of features. Based on his description of changes to Kwin core, merging new features from upstream must not be feasible at all.
          When a new Plasma release happens he syncs kwin git commits over to kwinft where appropriate, but as kwinft is no longer 1:1 as a fork due to replacing parts with wrapland and wlroots, any commits related to that won't be adopted/ported, and certain feature parity will differ. Eg, graphic tablet support (Wacom, Huion), and VR HMD (drm leasing) are two notable features that will differ in implementation, screen casting I think is another one.

          One feature being worked on recently with kwin is interactive real-time multi-touch gestures, which has some kwin effects animations sync to your gesture movement (eg a multi-finger swipe to change virtual desktop), rather than waiting on completion to trigger a transition like a shortcut key or mouse movement would. This requires effects to be updated to support them, and I think relies on libinput integration... however kwinft adopts wlroots for the next release, which shifts the responsibility of libinput there.

          Comment


          • #45
            Originally posted by oiaohm View Post
            Sorry C++ provides no real protection again use after free or memory leak bugs.
            https://www.zerotier.com/2017/05/05/...ndard-library/
            See also https://alexgaynor.net/2019/apr/21/m...-wont-save-us/

            Comment


            • #46
              Poke poke. Unapproved post.

              Comment


              • #47
                Originally posted by oiaohm View Post
                The horrible part here that is not true.
                https://googleprojectzero.blogspot.c...aping.html?m=1
                Turns out the very features in modern C++ that are meant to prevent use after free can in fact create them. We have real world exploit examples these days. The horrible reality is items like smart pointers were built on the foundation of C that results in them being like quick sand as in looks solid when its not.
                No, it IS TRUE.

                No one is saying that features like smart pointers completely eliminate use after free but they do have an impact on catching a subset of the errors. This is what you said earlier (bold emphasis is mine)

                Originally posted by oiaohm View Post
                The reality Steffo is use after free or memory leak bugs are just as likely with C++ as C. Ok some of the C++ ones instead of being a normal memory leak is a object leak but the result is still the same of memory not being freed when it should have been and the data end up exposed when it should not have been.
                This is blatantly false, misleading and spreading FUD. Yes C++ has plenty of issues, but claiming that modern C++ features are no better than C when it comes to memory safety is being disingenuous (you are literally claiming that smart pointers don't do anything which is laughable). And no, posting single bug reports on C++ where it didn't work is not proving your point because no one claimed that it prevents 100% of cases, in other words you are attacking a strawman (and if you wanted to be objective and honest you would have posted every single case in that project where the compiler did catch such errors, but of course you didn't).

                This is what pisses people off about your posts, you take some point and then you twist it ever/sensationalize to a degree where you deliberately mislead people. Stop doing it please.

                There are legitimate reasons why C++ is not the best suited language for this task (i.e. ABI that breaks much more frequently than C), however this false hill that you are standing on is not one of them.
                Last edited by mdedetrich; 15 June 2021, 04:37 AM.

                Comment


                • #48
                  Originally posted by mdedetrich View Post
                  This is blatantly false, misleading and spreading FUD. Yes C++ has plenty of issues, but claiming that modern C++ features are no better than C when it comes to memory safety is being disingenuous (you are literally claiming that smart pointers don't do anything which is laughable). And no, posting single bug reports on C++ where it didn't work is not proving your point because no one claimed that it prevents 100% of cases, in other words you are attacking a strawman (and if you wanted to be objective and honest you would have posted every single case in that project where the compiler did catch such errors, but of course you didn't).
                  Reality you need to pull you head in. My point of view is based on data mining the last 6 years of CVE for causes. Once you have seen that you will see the leaks that smart pointers cause out number the C ones.

                  use after free or memory leak bugs are just as likely with C++ as C < I stand by this statement and so will anyone else who has data mined the CVE list to see what is getting past compilers.

                  https://blog.scrt.ch/tag/use-after-free/
                  This is documented in 2017 where smart pointer functionality goes and causes a use after free event from the way it behaves. Its not like a rust or go protection where user cannot go and double allocate the same point to protection. C++ smart pointers have a critical flaw and no tooling to detect when a programmer has done it. So smart pointers no matter how you argue are not designed to prevent use after free. Due smart pointers not being processed by tool like address sanitiser these faults are keeping on happening at a high rate than C memory management errors.

                  Sorry the reality is smart pointers design is broken this is why they don't fix the use after free problem correctly it was document in 2017 and it about time mdedetrich you pull your head out the sand. Difference here is when a use after free is caused by a double allocation of smart pointers due to coder error the code looks a lot safer than its really is because of a miss belief that smart pointers are safe when they are in fact unsafe structures.

                  Comment


                  • #49
                    Originally posted by oiaohm View Post
                    use after free or memory leak bugs are just as likely with C++ as C < I stand by this statement and so will anyone else who has data mined the CVE list to see what is getting past compilers.
                    Well no shit a CVE list exposes cases where smart pointers don't work because otherwise it wouldn't be a CVE in the first place. Thats like saying Rust's borrow checker doesn't work because someone modifies an address using unsafe.

                    Again you are ignoring all of the times a CVE was prevented by the use of smart pointers

                    Originally posted by oiaohm View Post
                    https://blog.scrt.ch/tag/use-after-free/
                    This is documented in 2017 where smart pointer functionality goes and causes a use after free event from the way it behaves. Its not like a rust or go protection where user cannot go and double allocate the same point to protection. C++ smart pointers have a critical flaw and no tooling to detect when a programmer has done it. So smart pointers no matter how you argue are not designed to prevent use after free. Due smart pointers not being processed by tool like address sanitiser these faults are keeping on happening at a high rate than C memory management errors.
                    Right, but in the cases where you don't double allocate the same pointer in generally works so in those cases it would have catched potential memory leak issues. Again no one is claiming that C++ smart pointers are as good as Rust's borrow checker (its not) but you are basically saying it does nothing which is also untrue.

                    Originally posted by oiaohm View Post
                    Sorry the reality is smart pointers design is broken this is why they don't fix the use after free problem correctly it was document in 2017 and it about time mdedetrich you pull your head out the sand. Difference here is when a use after free is caused by a double allocation of smart pointers due to coder error the code looks a lot safer than its really is because of a miss belief that smart pointers are safe when they are in fact unsafe structures.
                    I didn't realize the only way you can do a use after free is from double allocation There are a lot of other cases of use after free which do get caught by the compiler which you are ignoring.

                    I mean do you want me to go through a list of CVE's in C programs and demonstrate how many of them would have been caught using modern C++?

                    Comment


                    • #50
                      Originally posted by mdedetrich View Post
                      This is what pisses people off about your posts, you take some point and then you twist it ever/sensationalize to a degree where you deliberately mislead people. Stop doing it please.
                      Can confirm this.

                      Comment

                      Working...
                      X