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.
Announcement
Collapse
No announcement yet.
KWinFT Going Through Code Refactoring, Working On WLROOTS-Based Usage
Collapse
X
-
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?
- Likes 1
Comment
-
Originally posted by Steffo View PostC++ 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.
Originally posted by Steffo View PostIt 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.I have been around the C++ community for a while to hear that raw pointers "are evil" and that they should be avoided as much as possible. While one of the main reasons to use smart pointers over raw
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 PostThis 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.
Posted by Mark Brand, Exploit Technique Archaeologist. Introduction After discovering a collection of possible sandbox escape vulnerab...
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
-
Originally posted by curfew View PostKwinft is developed for KDE so obviously it will maintain compatibility with KDE forever.
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 PostThe 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.
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
-
Originally posted by oiaohm View PostSorry C++ provides no real protection again use after free or memory leak bugs.
https://www.zerotier.com/2017/05/05/...ndard-library/
Comment
-
Originally posted by oiaohm View PostThe 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 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 PostThe 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 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.
- Likes 3
Comment
-
Originally posted by mdedetrich View PostThis 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).
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.
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
-
Originally posted by oiaohm View Postuse 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.
Again you are ignoring all of the times a CVE was prevented by the use of smart pointers
Originally posted by oiaohm View Post
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.
Originally posted by oiaohm View PostSorry 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 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++?
- Likes 2
Comment
Comment