Bad array indexing is considered deadly

Paolo Invernizzi via Digitalmars-d digitalmars-d at puremagic.com
Sat Jun 3 03:21:03 PDT 2017


On Saturday, 3 June 2017 at 07:51:55 UTC, Ola Fosheim Grøstad 
wrote:
> On Saturday, 3 June 2017 at 06:55:35 UTC, Paolo Invernizzi 
> wrote:
>> The worst thing happened in programming in the last 30 years 
>> is just that less and less programmers are adopting Walter 
>> mindset...
>
> Really?
>
> On the contrary. What is being adopted is robustness and 
> program verification. More and more.

It doesn't seems to me that the trends to try to handle somehow, 
that something, somewhere, who knows when, has gone wild it's 
coherent with the term "robustness".

And the fact that the "nice tries" are done at runtime, in 
production, is the opposite of what I'm thinking is program 
verification.

> Assuming that a program shouldn't be able to flush its buffers 
> out of some flawed reasoning about program correctness does not 
> support your argument at all.
>
> Even if your program is fully based on event-sourcing and can 
> deal with an immediate shutdown YOU STILL WANT TO FLUSH YOUR 
> EVENT-BUFFERS TO DISK!

There's a fundamental difference between trying to flush logs and 
trying to report what's happened, with the scope of gaining more 
information of what happened, and trying to "automagically" 
handle the fact that there's an error in the implementation, or 
in the logic, or in the HW.

> The argument Walter is follwing is flawed. If a failed assert 
> means you should not be able to flush to disk, then it also 
> means that you should undo everything the program has ever 
> written to disk.
>
> The incorrect program state could have occured at install.

The argument Walter is following is not flawed: it's a really 
beautiful pragmatic balance of risks and engineering way of 
developing software, IMHO.

> You have to reason about these things in probabilistic terms 
> and not in absolutes.

I'm trying to exactly do that, I like to think myself as a very 
pragmatic person...

/Paolo




More information about the Digitalmars-d mailing list