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

[Richard (Rikki) Andrew Cattermole]

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.