Sorry, total newb here. For memory safe code, would it be possible to borrow a trick from Rust and do the following with Zig:
i. All hand rolled, custom code must be provably safe, following memory management rules, or the code does not compile.
ii. Standard libraries, which have been examined in detail and thoroughly tested by thousands of software devs, could use heap allocation, arenas, reallocation, etc, that would not be directly available to custom code.
Using whiteboard:
struct bibliography:
name = "Unknown title"
author = "Unknown author"
uint_fast8_t numPages, numPics, numChapters
bibliography* Moby = { "Moby Dick", "Dick Moby", 250, 11} //object added to heap with ptr Moby, numChapters is initialized to 0
The compiler recognizes bibliography* as a unique pointer so that the memory space gets freed automagically (unless that space is immediately reallocated when Moby is slain). For your custom code, the compiler then allows this since it's using smart pointers.
However, if the program uses the standard library, the library writers would be free to come up with all sorts of fast, clever memory management, arenas, etc, since that code is peer-reviewed up the yin yang. That is to say that the code is carefully analyzed BEFORE the latest update to the compiler, which can therefore depend on its memory safety and ruggedness.
Most of the security problems with C/C++ are the result of programmers not following those strict memory management rules, so C#, Java, Python, etc, just use a garbage collector with lots of overhead and unacceptable stalls at runtime. Rust prevents code from compiling if the strict rules are not followed.
Using these two tools, no memory unsafe code would end up in production code.
Sorry, total newb here. For memory safe code, would it be possible to borrow a trick from Rust and do the following with Zig:
i. All hand rolled, custom code must be provably safe, following memory management rules, or the code does not compile.
ii. Standard libraries, which have been examined in detail and thoroughly tested by thousands of software devs, could use heap allocation, arenas, reallocation, etc, that would not be directly available to custom code.
Using whiteboard:
The compiler recognizes bibliography* as a unique pointer so that the memory space gets freed automagically (unless that space is immediately reallocated when Moby is slain). For your custom code, the compiler then allows this since it's using smart pointers.
However, if the program uses the standard library, the library writers would be free to come up with all sorts of fast, clever memory management, arenas, etc, since that code is peer-reviewed up the yin yang. That is to say that the code is carefully analyzed BEFORE the latest update to the compiler, which can therefore depend on its memory safety and ruggedness.
Most of the security problems with C/C++ are the result of programmers not following those strict memory management rules, so C#, Java, Python, etc, just use a garbage collector with lots of overhead and unacceptable stalls at runtime. Rust prevents code from compiling if the strict rules are not followed.
Using these two tools, no memory unsafe code would end up in production code.