[Not really OT] Crowdstrike Analysis: It was a NULL pointer from the memory unsafe C++ language.

[H. S. Teoh]

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