Announcement

Collapse
No announcement yet.

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

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

  • oiaohm
    replied
    Originally posted by Nth_man View Post
    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.

    Leave a comment:


  • Nth_man
    replied
    > > 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.
    Last edited by Nth_man; 01 July 2021, 02:11 AM.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by Nth_man View Post
    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.
    Last edited by oiaohm; 30 June 2021, 10:05 PM.

    Leave a comment:


  • AHOY
    replied
    Originally posted by tildearrow View Post
    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.

    Leave a comment:


  • Nth_man
    replied
    Originally posted by smitty3268 View Post

    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".

    Leave a comment:


  • tildearrow
    replied
    At this rate you should just rewrite the entire compositor.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by mdedetrich View Post
    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.


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

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

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

    Leave a comment:


  • smitty3268
    replied
    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.

    Leave a comment:


  • mdedetrich
    replied
    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++?

    Leave a comment:


  • oiaohm
    replied
    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.

    Leave a comment:

Working...
X