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

[Paolo Invernizzi]

On Thursday, 25 July 2024 at 11:47:21 UTC, Timon Gehr wrote:
> On 7/25/24 04:32, Walter Bright wrote:
>> On 7/22/2024 12:00 PM, Timon Gehr wrote:
>>> Anyway, the point is there should be a way to have the 
>>> compiler help you do this kind of safety scaffolding without 
>>> you needing to lie to the compiler.
>> 
>> I understand your design and it has merit.
>> 
>> Issues:
>> 
>> 1. the proliferation of these features. Have you seen all the 
>> C extensions VC and gcc have? It makes for an excessively 
>> large and intimidating language. The larger the specification, 
>> the less people will read it.
>> ...
>
> Hardly applies in any relevant fashion to pragmas that enable 
> additional type checking.
>
>> 2. if an existing feature can be pressed into service instead, 
>> adding a new feature needs a big advantage
>> ...
>
> You are in effect removing an existing feature.
>
>> 3. one of the earliest goals with D was to make it easier for 
>> managers and QA staff to have rules and enforce them. @trusted 
>> was always intended to be an easily greppable construct so 
>> that the QA reviewer knows where to focus his effort. A 
>> manager can lay down a rule "no level1 programmers can check 
>> in @trusted" and enforce it mechanically.
>> ...
>
> Well, your approach is essentially that your higher-level 
> programmers go around slapping `@trusted:` on files. I'll give 
> you that banning "level1 programmers" from checking in any code 
> at all probably does help safety.
>
>> 4. @trusted makes for a nice and easily grepped TODO list to 
>> measure progress on making the code actually safe
>> ...
>
> No, some uses of `@trusted` are inevitable. `@trusted` means: 
> "this has been audited and the author certifies that the 
> interface is safe".
>
> What you are describing is not `@trusted`, you are describing 
> `@yolo`: "this has not been audited at all but I need it to be 
> `@safe` anyway for marketing purposes".
>
>> 5. In a final release, @trusted should be quite rare. But it's 
>> up to the team to enforce it.
>> ...
>
> Well, what do you think I am doing here? You are behaving in a 
> way I deem irresponsible by promoting this way of using 
> `@trusted`.
>
>> 6. @trusted can absolutely be abused. But you can't hide it!
>> ...
>
> I am putting forward a critique of that abuse, which is indeed 
> plainly visible.
>
>> 7. Simple is better.
>> ...
>
> Apparently `@trusted` is already too complex for most people to 
> wrap their heads around it. It's a pity.
>
>> 8. Not needing to learn new things is better.
>
> The way you suggest `@trusted` should be used is a novelty. 
> It's a completely new attribute.

I totally agree with Timon here.

Lately I was speaking with a friend of mine, now a senior Nvidia 
manager, curious about what programming language we are using in 
DeepGlance as I claimed we care for memory safety. Guess what he 
should think about this thread, after having pointed it to

https://dlang.org/spec/memory-safe-d.html
"@trusted functions __MUST__ have a safe interface"

when he could see the language main author writing: `@trusted 
void list_delete(list_t list) { free(list); }`, advocating to 
slap trusted everywhere?

How you can think someone can just expose himself in advising D 
stating that??

I understand the problem you put on the table, but that MUST be 
solved with a new greppable attribute or a pragma, abusing 
@trusted. There's no plan B.

/P