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

[Don Allen]

On Sunday, 28 July 2024 at 14:25:14 UTC, Timon Gehr wrote:
> On 7/26/24 16:59, Guillaume Piolat wrote:
>>>
>> 
>> Not really big on @safe (where is the RoI????
>
> Well, I am perfectly fine with people just not using `@safe`. 
> However, when I actually want some dependency to be `@safe` 
> because it has to deal with potentially adversarial input, I'd 
> prefer if the author actually took some care to make the 
> interface solid.
>
>> where are the products that beat the competition by being 
>> safe),
>
> Then why would you even care to lie to prospective users? Just 
> don't use `@safe` at that point.
>
>> but when currently used @trusted has 2 different semantic 
>> meanings:
>> 
>> 1 - @trusted that means "I've audited that the @system 
>> function I call are memoy-safe.
>
> This is what it's being advertised as.
>
>> do not grep this, there is nothing to see"
>
> You can still grep to see if you agree with the assessment.
>
>> 2 - @trusted that means "TODO, this is necessary because I've 
>> slapped @safe on top and must go on with productive things. 
>> I'll get back later! I should have marked this @system in the 
>> first place. I promise i'll get back and fix it!!1"
>
> What is even the point? If you think maintaining a memory-safe 
> interface is a waste of time and a non-feature, something that 
> nobody actually needs, don't even attempt to do it.
>
> Either `@safe` is a feature we want in the language, then it 
> should be solid, or we'd be better off just removing it. What I 
> am not on board with is making `@safe` a priority while at the 
> same time abandoning memory safety in `@safe` code. This makes 
> no sense.

I'm guessing that your issue with all of this talk about memory 
safety is that you have no sense of a coherent plan. If I'm 
right, then I share your concern. This is not intended as a 
criticism of Walter, because I see defining and enforcing memory 
safety in D as a very hard problem, so it doesn't surprise me 
that a clear plan isn't apparent.

I think the difficulty is that D has its roots in C and C++, both 
notably memory-unsafe. D adds the garbage collector to the mix of 
stack- and manually-heap-allocated memory. Trying to provide 
compiler-enforced guarantees in the face of these disparate 
options is not a simple matter. Reading the "Function Safety" 
section of the language reference made my head spin. I think its 
complexity flows directly from the memory-management options D 
provides.

Rust avoids this problem by providing a single memory-management 
methodology that is imposed on the user. There are no choices. 
You do it the Rust way or your code won't compile.

I personally like that D offers the choices it does and in my own 
code, I avoid malloc/free and use of pointers as much as 
possible. I stack-allocate when feasible and GC-allocate when 
necessary. Talking to C code complicates things, something that 
bit me when I was first learning D (I passed a GC-allocated 
string to sqlite as a binding and failed to read the warning in 
the toStringz documentation about the string vaporizing in a 
subsequent garbage collection).

My own preference would be to first focus on improving the 
documentation of what is already in the language. What types get 
stack-allocated? GC-allocated? It's not always clear in the 
current documentation, e.g., I believe static arrays are 
stack-allocated; where does it say that? There are many other 
examples of this information not present in the documentation. 
The programmer needs to know this information to avoid unsafe 
memory-management practices, because what is required of the 
programmer depends upon the type of memory in question.

I think one of the great features of D is the ability of D and C 
code to talk directly without the need for an intermediate 
interface. The current documentation is a good start, but could 
be improved with more explanation and examples of how to this 
safely.

I think improved documentation would help to make people happier 
with D. I don't think D needs to be compiler-guaranteed memory 
safe, which is good because I don't think it's possible. There 
may be opportunities for the compiler to provide *some* help in 
this area that it presently doesn't, but I doubt that D will ever 
be able to make the assertions about memory-safety that Rust 
does. Note that Zig provides only stack- and manual 
heap-allocation. It is not a memory-safe language. But there's a 
lot of interest in it, despite not being close to release and a 
growing issue list.