[Development] Fornux C++ Superset

[Edward Welbourne]

Phil Bouchard (24 April 2018 19:05)
>>> I’m 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.

On 04/25/2018 04:46 AM, Edward Welbourne wrote:
>> 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.

Phil Bouchard (25 April 2018 14:02)
> You need to see the big picture;

Fun fact: when someone gives an example and I debunk it completely, they
always claim that I'm looking at the wrong example.
I'm never impressed.

Now, as concerns looking at "big pictures": I've been working in the
software industry for three decades (spread over three dozen years), in
a wide diversity of sub-industries, so I will hazard a guess that I have
a better grasp of the big picture than you're exhibiting.  In
particular, the market realities of the software industry are (by no
means the whole of, but still) a pretty important part of the big
picture.

If you ship something tolerably usable that solves problems for real
users today, you can use feed-back and/or revenue from those users to
improve your product rapidly, which wins the loyalty of users, while
your competitors who are still obsessing about not shipping until they
can't find any more bugs are getting no users and shall have an inferior
feature-set by the time they do ship; and may well have more bugs, that
they didn't find but the users will, than yours (in which you fixed the
bugs the users found already).  Buggy, useful and in the app-store today
beats vapourware that claims it'll be bug-free and along "real soon",
especially after the latter has been making those claims for any length
of time.

I note that C++ and Qt are "in the app store today".

> memory leaks are the most difficult problems to solve.

Well, no, they're not.
I've fixed *lots and lots* of memory leaks.
Some of them were a little tricky: most were trivial.
I can *see* memory leaks just by reading code.
It's one of the reasons code review makes memory leaks rare.
That and nice sensible disciplines like RAII.

Use-after-free is usually harder to solve than a leak.
Deadlocks are almost always harder to solve.

Some software teams (perhaps because their managers fear the costs)
don't adopt the widely-understood best practices that make leaks rare
and easy to solve.  Those teams end up with leaky code; and the leaks
are their biggest problem.  However, extrapolating from these poorly run
teams to the whole industry is misguided.  Those who've endured such
teams surely think leaks are the worst, but that's only because they've
taken a false economy: the (modest, up-front) cost of Doing The Job
Right In The First Place is dwarfed by the price of cutting corners.
The Dunning-Kruger effect then promises us that they'll write articles
in which they tell the rest of us that the consequences of their own
incompetence are the biggest problem facing the industry today.
They are, none the less, wrong.

> 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've had to fix the time-reporting code on a web server so that it
correctly handled DST transitions as they happened (without burdening
its performance in between transitions); this was necessary because we
measured expected uptime in years.  We did not have problems with memory
leaks.  We had problems with log messages with timestamps off by an hour
for half of each year (until I fixed this).

Incidentally, getting *that* right was also harder than fixing memory
leaks.  (If you think it's easy - just send a message to the right code
to tzset() just after the next transition - you've forgotten that the
date of next transition is controlled by capricious politicians who may
have moved the transition before that event triggers.  I coded round
that.)

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

I worked on the Opera browser, back when its engine was Presto, and we
fixed our share of leaks; which is one of the things that prompted us to
adopt code review, after which the overwhelming majority of leaks got
caught in review.  There were still plenty of other ways to crash,
though; and plenty of non-crash bugs that were potentially more annoying
for users.  (If the only work-around is to exit the browser and restart,
it may be better to have crashed so the user got the work-around when
the browser auto-relaunched itself, phoenix-like, from the ashes.)

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

Well, your life is a lot easier if most of your code is cross-platform,
so that your builds for desktop are using most of the same code that
your device builds use; that way, Valgrind testing on desktop will fix
all the memory leaks in the cross-platform code and you only need to
find the leaks in your device-specific code.

Meanwhile, before I'd ever heard of Valgrind, I was hunting subtle
memory abuses on bitty little devices (compared to which Android and iOS
are luxurious palaces) where gdbserver was my friend and judicious
output streamed over netcat helped us to track down what was going
wrong.  Leaks were less of an issue than use-after-free and kindred
abuses of pointers.  Oh, and image-handling code that assumes it's
running on a little-endian processor.

I believe you over-estimate the difficulty of finding memory leaks, or
of *avoiding writing them in the first place*, which is usually a better
plan.  Mature software development teams have solved this problem.
We don't need garbage-collection: we can do it in C++ or C just fine;
it's all a matter of appropriate discipline.  Meanwhile, the many other
kinds of bugs may be more troublesome than the authors you quote
understand,

	Eddy.