On 17/12/2024 3:10 AM, Lance Bachmeier wrote:
> On Sunday, 15 December 2024 at 12:05:46 UTC, matheus wrote:
> 
>> Some people are lazy and they will just write/do things to get the job done unfortunately.
> 
> "Lazy" and "unfortunately" are not accurate. Memory safety comes with a non-trivial cost, and in many cases, no benefit.

Neither is this fully accurate.

Memory safety when it properly models memory movement, does offer benefits in terms of optimization. Both logical bugs, and memory safety related issues can be caught.

Full program security analysis is incredibly expensive and I honestly don't think D will ever have it. You basically need a proof assistant at that point and you have to ditch the separate compilation model.

But there is a certain amount we can do, without going into a multi-pass DFA, whilst still being separate compilation. That can catch logic bugs and provide optimizations without being crazy on the unnecessary errors.

The question therefore, is how to tune it, and that is not an easy question to answer (still working on that one!).

A lot of this is bread and butter topics of backend engineers from the 80's. It is being reapplied to the frontend these days, rather than being a whole new area of research.

On Monday, 16 December 2024 at 14:24:53 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 17/12/2024 3:10 AM, Lance Bachmeier wrote:
>> On Sunday, 15 December 2024 at 12:05:46 UTC, matheus wrote:
>> 
>>> Some people are lazy and they will just write/do things to get the job done unfortunately.
>> 
>> "Lazy" and "unfortunately" are not accurate. Memory safety comes with a non-trivial cost, and in many cases, no benefit.
>
> Neither is this fully accurate.
>
> Memory safety when it properly models memory movement, does offer benefits in terms of optimization. Both logical bugs, and memory safety related issues can be caught.

But that's only a benefit if the optimization matters. For most of what I do, it doesn't. If you use the GC for your D code but interact with C libraries, you have the PITA of the compiler saying something's not memory safe, but 100% of the time spent getting it to compile is memory safety theater.

On 12/16/2024 9:16 AM, Lance Bachmeier wrote:
> But that's only a benefit if the optimization matters. For most of what I do, it doesn't. If you use the GC for your D code but interact with C libraries, you have the PITA of the compiler saying something's not memory safe, but 100% of the time spent getting it to compile is memory safety theater.

Whenever I review C code, I look for strncpy calls. It's nearly always buggy. Using the GC with it won't help.

In my revisions of old code to use safe practices, it has resulted in more understandable code. The only slowdown was the use of array bounds checking (using the GC won't help with that, either).

On Monday, December 16, 2024 2:47:27 AM MST Kagamin via Digitalmars-d wrote:
> On Saturday, 14 December 2024 at 10:20:34 UTC, Jonathan M Davis wrote:
> > If I want a function to be @safe, I'll mark it with @safe, and I'll get all of the appropriate checks.
>
> It's not always trivial. For example, I have an array copy function, it takes two arrays and calls memmove on them. It's, like, 80% safe, but it's not obvious what it would take to make it safer.

Whether we're talking about @safe or -preview=safer, they're both going to flag @system operations, requiring that a function that has @system operations be either @system or @trusted. The difference is that if you have a function that can be marked with @safe, and you mark it with @safe, you have a function that can be called from other @safe functions, whereas with -preview=safer, all you've done is track down instances where your code is doing @system operations (and you're then forced to explicitly mark the function as @system if it can't be @trusted). You still have to mark the function @safe or @trusted to be able to call it from @safe code.

As for how to make @system code be @safe, the only way to do that is to use @trusted. The question then is where exactly @trusted should be used, and that's obviously going to depend on the code in question. In principle, when you mark a function as @trusted, you're promising that it's 100% memory-safe in spite of the fact that it's doing something that's @system (though that obviously relies on the assumption that there are no compiler bugs which impact memory-safety and that all of the @trusted code that's being called is actually memory-safe).

If you have a function that's doing something with its arguments which are @system, and whether you can guarantee that it's actually @safe depends on the arguments that are given such that you can't guarantee that the code is memory-safe based solely based on what the function itself is doing, then that generally means that the function should be marked as @system, and it should then be documented what the requirements for the arguments are in order for what the function is doing to be memory-safe. Then the caller would make sure that it was passing in valid arguments and be marked @trusted.

One example of something like this would be a function like free. For free to be considered memory-safe, you have to pass it the correct arguments (otherwise, you can get issues like double-frees). So, free has to be @system, and it's the caller's responsibility to make sure that it's passing valid arguments to free. And if it does that, then it can be marked @trusted.

As to whether your particular function can be marked @trusted, I don't know, but it sounds like it probably can't be. If you can't be sure that the function is actually memory-safe, then that generally means that it's either doing something wrong that needs to be fixed, or that its memory safety depends on its arguments, in which case, the @trusted needs to be further up the call stack. But it's the kind of thing which really depends on what exactly the code is doing. In principle, to be able to mark a function as @trusted, it has to present an @safe API, since it's supposed to be impossible for an @safe function to doing anything that isn't memory-safe.

Either way, if you screw up and put @trusted in the wrong place, at least you know where to look when something happens which involves memory-safety having been violated, since only @trusted code can cause @safe code to do something that isn't memory-safe.

You might want to check out this blog post by Paul Backus:

https://pbackus.github.io/blog/what-does-memory-safety-really-mean-in-d.html

- Jonathan M Davis