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

[Don Allen]

On Monday, 29 July 2024 at 14:05:47 UTC, Timon Gehr wrote:
> On 7/28/24 20:51, Don Allen wrote:
>> On Sunday, 28 July 2024 at 18:21:41 UTC, Timon Gehr wrote:
>>> On 7/28/24 18:12, Don Allen wrote:
>>>> ...
>>>>>
>>> [snip]
>>>
>>> I mean, not really. You can manipulate raw pointers to 
>>> stack-allocated memory in Rust too, it just will not be safe.
>> 
>> I was talking about 'safe' Rust. I thought that was obvious. 
>> Apparently not.
>> ...
>
> It seemed to me like you were contrasting safe Rust with full 
> D, while at the same time buying Rust's safety marketing, but 
> not the one of @safe D, when they are actually largely similar.

Not my intent at all. I was contrasting the options for memory 
management we have in D with the box (pun intended) you are in 
when using Rust.

>
>> [snip}
>>>
>>> Rust will never be able to make the assertions about memory 
>>> safety that people seem to think Rust makes about memory 
>>> safety.
>> 
>> I don't think there's any doubt about the assertions Rust 
>> makes about memory safety in code that does not have the word 
>> 'unsafe' anywhere.

Here I was simply stating the obvious -- that we know what the 
Rust people are saying about memory safety. It was a weak attempt 
at a joke.

>
> In the real world, systems that have not been formally verified 
> typically have some flaws. If you don't have doubts, question 
> why that is.
>
>> Are you saying that they are lying?
>> ...
>
> They are not lying about their aspirations, I assume, but the 
> reality is indeed not quite there:
> https://github.com/Speykious/cve-rs

I was not aware of this -- interesting work -- but it does not 
surprise me. What Rust is trying to do is very difficult and I'm 
not surprised that it isn't perfect. This person has found edge 
cases that Rust doesn't handle. It's similar to getting on an 
airliner, which we're all told is "safe", despite the fact that 
they do crash. But would you rather go somewhere on an airliner 
or a motorcycle?

The probabilities matter. If language                             
                                                            
-assured memory safety is important to you, Rust is a  good 
choice *if* you are willing to pay the price in language 
difficulty *and* you have a real-time constraint.

>
> In any case, my point was more that people seem to hype safe 
> Rust and you were comparing that hype to a somewhat overly 
> skeptical view of D. This is not an apples to apples comparison.

I really don't understand how you got that from what I wrote. 
Perhaps I wasn't clear.

My intent was to say that I prefer the D way. I appreciate the 
memory-management choices D provides; I don't appreciate being 
forced to do things the Rust way, particularly in view of the 
difficulty of complying with all its rules. In D, I've found my 
own memory-management approach, using a subset of what the 
language makes available, and for the work I'm doing, writing 
safe, reliable D code (and maintaining it) has been far easier 
than the same in Rust. This is related to discussions I've had 
with Rust fans (not always cordial) in which I said that I didn't 
think the Rust GC-less approach to memory safety was worthwhile, 
because of the lack of a gc made the language so demanding, for 
writing garden-variety applications that did not have real-time 
constraints.

My concerns about D are *not* about memory management and safety 
but about its complexity, especially the parts of the language 
that feel to me like they were glued on in response to what 
others were doing. I don't want to see more such warts on the 
language. If the language can be extended to assist people to 
write safe code in ways that are natural, coherent *and* 
comprehensible (again, I cite the "Function Safety" section of 
the language document as an example of things going the wrong 
way, in my opinion), then great.