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