On Fri, Jul 26, 2024 at 07:07:44AM +1200, Richard (Rikki) Andrew Cattermole via Digitalmars-d wrote: [...]
> I am already convinced that there was multiple failures went on.
> 
> I was able to determine them just from the failures I was seeing on Twitter a few hours in.
> 
> But, I can't solve those.
> 
> I can however solve forcing a D user to check for nullability, and if that is the best that we can do, then that's all we can do.

Null checking doesn't solve this particular problem, though.  We just got lucky that the file contained zeroes.  If the file had contained non-zeroes that weren't what the code was expecting, treating that as a pointer may have lead to even more disastrous consequences.  A null check won't save you then.  (I've actually seen this before, in case you think this is theoretical.)


T

-- 
I've been around long enough to have seen an endless parade of magic new techniques du jour, most of which purport to remove the necessity of thought about your programming problem.  In the end they wind up contributing one or two pieces to the collective wisdom, and fade away in the rearview mirror. -- Walter Bright

On 26/07/2024 7:30 AM, H. S. Teoh wrote:
> On Fri, Jul 26, 2024 at 07:07:44AM +1200, Richard (Rikki) Andrew Cattermole via Digitalmars-d wrote:
> [...]
>> I am already convinced that there was multiple failures went on.
>>
>> I was able to determine them just from the failures I was seeing on
>> Twitter a few hours in.
>>
>> But, I can't solve those.
>>
>> I can however solve forcing a D user to check for nullability, and if
>> that is the best that we can do, then that's all we can do.
> 
> Null checking doesn't solve this particular problem, though.  We just
> got lucky that the file contained zeroes.  If the file had contained
> non-zeroes that weren't what the code was expecting, treating that as a
> pointer may have lead to even more disastrous consequences.  A null
> check won't save you then.  (I've actually seen this before, in case you
> think this is theoretical.)
> 
> 
> T

I don't think that this is a theoretical problem at all. I considered this ages ago.

For D we've solved all the non-null pointer safety issues with ``@safe`` that we can solve.

The only thing left is nullability which would have protected against the symptom and therefore prevented the outage.

On Fri, Jul 26, 2024 at 07:42:43AM +1200, Richard (Rikki) Andrew Cattermole via Digitalmars-d wrote:
> On 26/07/2024 7:30 AM, H. S. Teoh wrote:
> > On Fri, Jul 26, 2024 at 07:07:44AM +1200, Richard (Rikki) Andrew Cattermole via Digitalmars-d wrote:
[...]
> > > I can however solve forcing a D user to check for nullability, and if that is the best that we can do, then that's all we can do.
> > 
> > Null checking doesn't solve this particular problem, though.  We just got lucky that the file contained zeroes.  If the file had contained non-zeroes that weren't what the code was expecting, treating that as a pointer may have lead to even more disastrous consequences.  A null check won't save you then.  (I've actually seen this before, in case you think this is theoretical.)
[...]
> I don't think that this is a theoretical problem at all. I considered this ages ago.

How does null prevention solve the case of garbage data read from file being cast into a pointer?  A null check won't save you from that.


> For D we've solved all the non-null pointer safety issues with ``@safe`` that we can solve.
> 
> The only thing left is nullability which would have protected against the symptom and therefore prevented the outage.

Only in this particular instance.  It wouldn't have prevented anything
had the file contained unexpected data other than zeroes.


T

-- 
A linguistics professor was lecturing to his class one day.
"In English," he said, "A double negative forms a positive. In some
languages, though, such as Russian, a double negative is still a
negative. However, there is no language wherein a double positive can
form a negative."
A voice from the back of the room piped up, "Yeah, yeah."

On 26/07/2024 8:59 AM, H. S. Teoh wrote:
> On Fri, Jul 26, 2024 at 07:42:43AM +1200, Richard (Rikki) Andrew Cattermole via Digitalmars-d wrote:
>> On 26/07/2024 7:30 AM, H. S. Teoh wrote:
>>> On Fri, Jul 26, 2024 at 07:07:44AM +1200, Richard (Rikki) Andrew Cattermole via Digitalmars-d wrote:
> [...]
>>>> I can however solve forcing a D user to check for nullability, and
>>>> if that is the best that we can do, then that's all we can do.
>>>
>>> Null checking doesn't solve this particular problem, though.  We
>>> just got lucky that the file contained zeroes.  If the file had
>>> contained non-zeroes that weren't what the code was expecting,
>>> treating that as a pointer may have lead to even more disastrous
>>> consequences.  A null check won't save you then.  (I've actually
>>> seen this before, in case you think this is theoretical.)
> [...]
>> I don't think that this is a theoretical problem at all. I considered
>> this ages ago.
> 
> How does null prevention solve the case of garbage data read from file
> being cast into a pointer?  A null check won't save you from that.
> 
> 
>> For D we've solved all the non-null pointer safety issues with
>> ``@safe`` that we can solve.
>>
>> The only thing left is nullability which would have protected against
>> the symptom and therefore prevented the outage.
> 
> Only in this particular instance.  It wouldn't have prevented anything
> had the file contained unexpected data other than zeroes.
>   
> 
> T

It doesn't solve the underlying issue, I acknowledge that, but it would force the question on validation which obviously wasn't being asked.

It did crash the computers. But AFAIK, nobody said any data was corrupted or lost.

Without hardware memory protection, this could have been much much worse.

On 7/25/2024 12:07 PM, Richard (Rikki) Andrew Cattermole wrote:
> I can however solve forcing a D user to check for nullability, and if that is the best that we can do, then that's all we can do.


The hardware already does that.

On 7/25/2024 12:42 PM, Richard (Rikki) Andrew Cattermole wrote:
> The only thing left is nullability which would have protected against the symptom and therefore prevented the outage.

If your null check is:

    assert(p != null);

when it trips, your program exits, causing the outage.

Assert's are for detecting programming bugs. There is no recovery from programming bugs, because the program has entered an unknown state and cannot be relied on for anything.

On 7/25/2024 2:04 PM, Richard (Rikki) Andrew Cattermole wrote:
> It doesn't solve the underlying issue, I acknowledge that, but it would force the question on validation which obviously wasn't being asked.

The hardware will not only check for null pointer accesses, but check for *any* pointer that points to an address that is not mapped to the process.

On 26/07/2024 6:57 PM, Walter Bright wrote:
> It did crash the computers. But AFAIK, nobody said any data was corrupted or lost.
> 
> Without hardware memory protection, this could have been much much worse.

Yes as a fallback it did potentially prevent corrupting the kernel silently and that is a good thing!

No arguments against the MMU acting in this way.

However where we are differing is not that the MMU did good, but that it is a fallback.

If the MMU is throwing an exception something has gone terribly wrong elsewhere and having a programming language force you to check for null is a reasonable precaution against this.

There is a reason why application VM languages have over the last 15 years been adopting such analysis. They may control the process & threads, but even then it still makes sense to prevent such errors.

On 7/26/2024 3:21 AM, Richard (Rikki) Andrew Cattermole wrote:
> If the MMU is throwing an exception something has gone terribly wrong elsewhere and having a programming language force you to check for null is a reasonable precaution against this.

```
assert(p != null); // throws an unrecoverable exception
```

Array bounds errors also throw an unrecoverable exception