Program logic bugs vs input/environmental errors

[Walter Bright via Digitalmars-d]

On 11/9/2014 1:12 PM, Dicebot wrote:
> On Monday, 3 November 2014 at 03:29:05 UTC, Walter Bright wrote:
>> It is absolutely different because of scale; having 1K of shared memory is
>> very different from having 100Mb shared between processes including the stack
>> and program code.
> It is possible to have minimal amount shared mutable memory inside one process.

D's type system tries to minimize it, but the generated code knows nothing at 
all about the difference between local and shared memory, and has no protection 
against crossing the boundary. Interprocess protection is done via the hardware.


> There is nothing inherently blocking one to do so, same as there is nothing
> inherently preventing one to screw the inter-process shared memory. Being
> different only because of scale -> not really different.

Sharing 1K of interprocess memory is one millionth of the vulnerability surface 
of a 1G multithreaded program.


> What is huge advance for user land applciation is a problem for server code.
> Have you ever heard "OS is the problem, not solution" slogan that is slowly
> becoming more popular in high load networking world?

No, but my focus is what D can provide, not what the OS can provide.


> Preventing cleanup can be done with roughly one line of code from user code.
> Enabling it back is effectively impossible. With this decision you don't trade
> safer default for more dangerous default - you trade configurable default for
> unavoidable.
>
> To preserve same safe defaults you could define all thrown Errors to result in
> plain HLT / abort call with possibility to define user handler that actually
> throws. That would have addressed all concernc nicely while still not making
> life of those who want cleanup harder.

There is already a cleanup solution - use enforce().


>> That's correct, but not a justification for making it less reliable.
> It is justification for making it more configurable.

In general, some things shouldn't be configurable. For example, one cannot mix 
3rd party libraries when each one is trying to customize global behavior.


> My personal perfect design would be like this:
>
> - Exceptions work as they do now
> - Errors work the same way as exceptions but don't get caught by catch(Exception)
> - assert does not throw Error but simply aborts the program (configurable with
> druntime callback)
> - define "die" which is effectively "assert(false)"
> - tests don't use assert

Having assert() not throw Error would be a reasonable design choice.