>> memory leaks are the most difficult problems to solve Really NOT !
Philippe On Wed, 25 Apr 2018 08:02:54 -0400 Phil Bouchard <philipp...@gmail.com> wrote: > On 04/25/2018 04:46 AM, Edward Welbourne wrote: > > Phil Bouchard (24 April 2018 19:05) > >> Im not sure if you read the link I posted about static analysis but a > >> software bug can cause billion dollar projects like space shuttles to fail. > >> Maybe MS Word was a bad example but they can be very costly. > > > > The Columbia crash wasn't a (computer) software issue. One can think of > > the organisational failure that lead to it as a (human) software issue, > > but I don't think we have static analysis software for that. The > > closest you'll get is an ISO 9000 compliance auditor. > > > > The Ariane 5 crash was a software error, but it wasn't a memory abuse; > > it was using an under-sized integer to hold a value that overflowed. > > With luck, static analysis would find that, but it's a pointer abuse. > > > > The loss of the Mars Climate Orbiter involved a software bug, but it was > > a wrong choice of units rather than a pointer abuse. Mixing archaic > > silly units with sensible SI ones has caused more grief for space > > missions than pointer abuses. > > You need to see the big picture; memory leaks are the most difficult problems > to solve. In the labs you stress-test your software for a few days but in > real life your software is going to run for a few months consecutively. > > I was working for a WebKit-based browser for TVs for a software company and > the browser kept crashing after a day of usage because of memory leaks. I > mean how are you supposed to watch TV if you need to reboot the set-top box > every day at a random time? > > Also do you really want to spend time running Valgrind on iPhones or Androids > to find these problems? First Valgrind won't fix the problem, second it is > not giving always the same answer and third it doesn't run on all embedded > devices. > > There is more you can read about the subject here: > > "Real Production Issue - Hard to find memory leaks" > https://www.linkedin.com/pulse/c-hard-find-memory-leaks-vidhut-singh > > And BTW: > > "Garbage collection is out the window, because you cannot know when it is > going to happen or how long it will take, which leads to stuttering frame > rates." > https://www.quora.com/How-do-game-studios-prevent-memory-leaks-in-complex-C++-games > > > So bugs can have disastrous consequences, sure; but fixing all pointer > > abuses won't stop that from being the case. Meanwhile, in the world of > > most programmers, most bugs are more or less endurable and most users > > would sooner have something that ships today with a few endurable bugs > > than not have the software that helps them do whatever it is they do > > until someone is sure there are no bugs in it. Buts aren't the only > > thing that can cause a software project to fail. > > > >> Also it is possible for me to support nested structures by prefixing class > >> names so that their meta-data fits into the top-level namespace but for the > >> moment theyre not. But those are personal preferences like not using > >> underscores in function names, etc. > > > > Well, if you can support nested structures, you might have a better > > chance of persuading folk to port to your new language; but those with > > large code-bases aren't about to re-write them to eliminate nested > > structures just because you regard that choice as a personal preference. > > I note that Qt has plenty of nested structures. > > I'm not volunteering to refactor them away. > > Support for nested structures is easy to fix and will just take a day or two > to do so. For example: > > struct A > { > struct B > { > }; > }; > > Will be converted into the following so that I can have their specialization > in a top-level namespace: > > struct A__B > { > }; > > struct A > { > }; > > Since there is no hidden catch then I will tell you right now that: > - NULL C pointers will need to be typed > - pointer casts to their encompassing structure needs to use _containerof() > macro > - C-style array parameters needs to be converted to pointers > - Types instantiated in the same statement need not be different (Ex.: int * > i, j[4]; // needs to be 2 different statements) > > That's about it. It took me 1 week to adapt "libarchive" to follow the > aforementioned rules: > https://github.com/philippeb8/libarchive/commit/5858b5c047301123ffdf05f247f7d191829d5a9b > > > Regards, > -Phil > > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
