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

[oiaohm]

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

No I am not. The reality here is the number of times a CVE issue could be prevent by smart pointers that are being reported has reduced. The reason why this has happened is not that projects have changed on mass to C++ but C has got better tooling in C compilers.

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.

Problem here is double allocation of smart pointers happen lot more common that one would like. Lets say someone has a super bent on using modern C++ in a library that provides C interfaces and then you have C++ wrapper for applications on top of that and that person has a super bent on using modern C++. This is one of the common cases that causes use after free with modern C++. The problem being the smart pointer use counter getting to zero and it auto freeing.

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 am not really. The case that AddressSanitizer in the compiler has caught the use after free error so the compiler refuses to build the result is that fault no longer makes it into production.

By not counting the fault the compiler catches is being fair. Yes the C language was not modified to prevent particular problems instead the compiler was the result is different.

There is a difference between in theory better and real world provable better. Counting the flaws that you could do by theory using the C language specification does mean a person can still use them.

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++?

Problem is I have already done that. The reality is I did it fairly. I looked at CVE that Modern C++ has caused as well. I have noted down that a lot of C CVE types don't happen any more. Not that the C language changed but directly because of the tooling change.

Smart pointers go wrong because they are based on C pointers. Lot of modern C++ so called fixes to C CVE when you look closer they are not a generic fix just like Smart pointers there is now a harder to see corner case.

Modern C++ does not have a mathematical proof to prove it safe. So its like using rust constantly in unsafe mode in fact C++ way more dangerous in a lot of ways due to how many hidden operations are defined into Modern C++ like the smart pointer one free when X counter gets to zero so now is freeing memory at a point programmer many not be expecting.

mdedetrich the reality when you look at code that will build on modern day compilers C++ is no safer than C in fact C++ can be less safe than C due to how hard to see the faults are due to hidden operations.

The hard reality is modern C++ stuff has not really fixed the problems. Just like AddressSanitizer does not find all the C memory errors. The problem here is modern C++ adds it own set of issues that result in for every C issue modern C++ fixes that would not be detected by compilers the modern c++ creates at least 1 more fault to replace it.

I would love for the C++ standard to admit that smart pointers are screwed and move to something that could in fact work in all cases or at least works in safe code always. Yes this could be mandating tooling on compilers by making particular usages of smart pointers illegal by standard. Yes it perfectly legal to C++ standard to double safe pointer the same C pointer so creating use after free by C++ standard and compilers have not chosen to forbid it at this stage. There are issues with modern C++ standard threading and other things that also create hard to see CVE issues in code.

C++ like it or not is not a solution in it current form. Claiming C++ is better than C when looking at real world usage does not hold up. By accepting the false fact that C++ is safer than C means there is no pressure back on the C++ standard to fix the standard to truly be better than C.

[tildearrow]

At this rate you should just rewrite the entire compositor.

[Nth_man]

Originally posted by @Steffo
> You just ignore concepts like RAI and smartpointers which are far superior than goto.

Originally posted by @mdedetrich
> 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.

Confirmed there, too. Also, if you let him, he also writes falsehoods like "Qt, where you no longer get the security updates or new features if you don't pay".

[AHOY]

At this rate you should just rewrite the entire compositor.

Yes, please. They seem to have a similar opinion about refactoring that I do. And when they removed activities I knew they had good taste, and also removing Qt and going with wlroots. I like the idea of activities and would love to use them but the complexity and interaction with other pieces of a desktop is just terrible. That's why I never adopted that in my workflow.

I hope that by the first real release as a finished product they end it up with 1/3 the size of KWin or at least half the complexity.

[oiaohm]

Confirmed there, too. Also, if you let him, he also writes falsehoods like "Qt, where you no longer get the security updates or new features if you don't pay".

Sorry that was not a falsehood because what I was saying the Qt company did say they were going to-do before changing their mind. When company does say they will do something then changes their mind they can decide to change back in future. Totally does not pay to ignore what they did.

The reality here that post line does not prove me at fault here. All it proves is that you Nth_man only looked at the current state not the state the KDE developers got over turned that Qt was going to-do before the KDE developers argued. Yes just because someone leaves something alone does not mean you were right Nth_man. I left it alone because I just accepted you were too stupid to accept the facts of the event and apparently you are still too stupid.

[Nth_man]

> > Confirmed there, too.

> stupid

Ha, ha, not only saying unfounded opinions dressed as facts, oiaohm also insults when several people confirm what he does. He ran out of anything that could be considered factual and is resorting to childish retorts. Shame.

Feel free to write though I'm done reading more of the same and have much better things to do.

[oiaohm]

Ha, ha, not only saying unfounded opinions dressed as facts, oiaohm also insults when several people confirm what he does. He ran out of anything that could be considered factual and is resorting to childish retorts. Shame.

Feel free to write though I'm done reading more of the same and have much better things to do.

No go back and read it was not unfounded options. This is still you being the stupid one who has not read the documented I provide that I did not write that I was base my option. So my option is not baseless. Yours against me there was and still is.