On Friday, 11 November 2022 at 18:24:46 UTC, Nick Treleaven wrote:
> > >Just declare main @safe.
Have you missed my comment, which was talking about exactly that?
You didn't mention main.
I apologise. I didn't think that you are unfamiliar with this particular language construct. Check https://dlang.org/spec/attribute.html and search the "affects all declarations until the end" substring to find the relevant part of documentation.
Basically you can put "@safe:" in the beginning of your program and all functions (the main function too) will be @safe by default.
> > >Memory unsafety is non deterministic. Overflow/underflow is, so it's much less important.
Neither is deterministic. Unless you have strictly deterministic input data.
Whatever the input data, without memory safety you can't trigger the bug through testing alone. It might never occur
on your system, only on your client's.
There may be certain input data patterns, which are not properly stressed by your local testing setup. And only manifest themselves on a client's system. If that's not enough to convince you, there are also many CVEs that mention "integer overflow".
Moreover, paged virtual memory used in modern computers already provides some kind of rudimentary memory safety (with page granularity). Your client may get a "segmentation fault" error with a core dump or a crash dump file, which can be used by you to debug the issue. Debugging an arithmetic overflow bug may be a lot more tricky.
>That's why the NSA recognises memory safety bugs as categorically worse
than logic bugs or overflow/underflow.
Can you prove this claim by providing a citation?