Why doesn't godot use some sort of c++ memory analyzer for ensuring godot is memory safe?

[Shadowblitz16]

We all know rust is praised for it's memory safety, however it's not really realistic to rewrite the whole godot engine in rust.

So why doesn't use some sort of memory safety analyzer with all warnings as errors?

C# has memory safety analyzers and I heard there is something called val-grind for c++

Sorry if I don't know what I am talking about. it's just a question.

[timothyqiu]

There're some related options you can turn on when building godot. For example, use_asan=yes enables the address sanitizer and use_msan=yes enables the memory sanitizer.

BTW, memory errors are not special. They are just one of the many types of errors an application might encounter.

[AThousandShips]

So a couple of things that play into this I believe:

1. Memory checking systems aren't free, they invariably incur performance and memory overhead, you always need to add some system to check it, and some system to track and manage the feature. Depending on the implementation this can even mean adding at least some data to each allocation made, Godot aims to reduce overhead both performance and memory in release builds, which is why we exclude build symbols and a lot of debug checks for example
2. AFAIK there's no easy or good cross-platform solution for this for c++, as the language itself doesn't offer a system built-in (unlike Rust or C#) and there's no rules or aspects of it in the specs (which would make it easier to have it supported in different compilers), MSVC is from what I've seen and heard notorious for being hard to integrate tools with for example (though it does support asan, but only asan). So the focus has been on providing a broad memory safety system for selected platforms for development purposes (which is already used in the CI for the Linux/BSD platform). Having this be a fully cross-platform feature for production use would involve a lot of extra work to make it work reliably on all platforms and preferably all compilers.

For my part my philosophy generally is that memory issues should be something that we shouldn't expect in production code and adding checks for it to release builds is an unnecessary and unwanted expense. Memory errors should be identified during the building process and fixed, and when the engine is used correctly and works correctly they shouldn't happen thanks to checks and design making sure we use memory responsibly. But the feature should still be available during development to be able to catch things, or to pin down bugs easier

tl;dr: It isn't an easy problem to solve reliably and uniformly due to the nature of c++ and library support, it is expensive, and shouldn't be needed in production builds if the code is written properly, so for "why isn't there a memory analyzer in release builds/by default" that would be my answer (otherwise the answer is "there is one but you have to turn it on")

[Shadowblitz16]

Ok thankyou for explaining.