03-05-2024, 10:15 PM
The MinGW usage of QB64PE is largely an implementation detail, the important questions are about the language itself and what it can or cannot do. Languages like Rust ultimately compile down to native code the same as we do and could produce native code with memory safety issues - it's the language design that allows the compiler and/or runtime to prevent memory-safety issues that ultimately makes them "memory-safe" languages.
For the QB64PE language, I would say it's mostly a memory-safe language, but definitely not entirely. It doesn't have pointers or references, so most of the typical issues aren't even possible, and Strings and arrays are bounds checked when you use them. The language however is not memory-safe if you make any use of `_MEM` - specifically either using `_MEM` with `$CHECKING:OFF`, or using the `_MEM(offset, len)` syntax.
Other usages of `_MEM` do get bounds checked to the region the `_MEM` is made for and should always be memory-safe, but I would personally not bet in there being no situations where you could screw it up or write over a pointer or something. For example, we allow you to do `_Mem(m)` where `m` is another `_Mem` type (that's probably a bug), doing that can allow you to break the bounds checking. Many languages on the list do allow you to break bounds checking intentionally, so that's not strictly a deal breaker, but it does make the situation a bit unclear.
From an implementation standpoint though, the QB64PE runtime is written in C++ (and really, not the best C++), and there's plenty of things in QB64PE that are buggy and will cause memory safety issues even if they shouldn't. Ex. This is a memory safety bug in the runtime that could be triggered by QB64PE code.
For the QB64PE language, I would say it's mostly a memory-safe language, but definitely not entirely. It doesn't have pointers or references, so most of the typical issues aren't even possible, and Strings and arrays are bounds checked when you use them. The language however is not memory-safe if you make any use of `_MEM` - specifically either using `_MEM` with `$CHECKING:OFF`, or using the `_MEM(offset, len)` syntax.
Other usages of `_MEM` do get bounds checked to the region the `_MEM` is made for and should always be memory-safe, but I would personally not bet in there being no situations where you could screw it up or write over a pointer or something. For example, we allow you to do `_Mem(m)` where `m` is another `_Mem` type (that's probably a bug), doing that can allow you to break the bounds checking. Many languages on the list do allow you to break bounds checking intentionally, so that's not strictly a deal breaker, but it does make the situation a bit unclear.
From an implementation standpoint though, the QB64PE runtime is written in C++ (and really, not the best C++), and there's plenty of things in QB64PE that are buggy and will cause memory safety issues even if they shouldn't. Ex. This is a memory safety bug in the runtime that could be triggered by QB64PE code.