"Never reads uninitialized memory". Hmm. That's tough. All structs always 1-byte packed, no padding. No SIMD optimized string functions. How about "No outcome ever depends on uninitialized memory"?
The typical way to address this is to ensure that all memory is zero initialized. This is all at the language level of abstraction not the processor, so it is sufficient for the language not to leak information about the content of padding.
@@SeanParent It'll take a while to put all those worms back into the can. Will MSAN still report errors when reading such unintentionally initialized memory?
Ada was designed with safety in mind without minimal impact on performance and resource efficiency. Unlike C++, the programmer just writes Ada code without concerning themselves with how its semantics impacts its execution and size.
Signed integer overflow.... defining that behaviour does not make it any worse cause the compiler already is allowed to assume that it NEVER can happen which means if your code experiences overflow you ALREADY can not do anything about that. Hell because the compiler is allowed to assume it is also allowed to remove ANY AND ALL CODE that tries to check if such an overflow occured. The one thing this undefined behaviour does it give the compiler a bit more playroom with optimisation. Worse than just these problems occurring at runtime are the various things that cause "ill-formed no diagnostic required" - aka the compiler can (and mostly does) know that your code is not valid C++ but does not need to tell you and can do whatever bullshit.
" defining that behaviour does not make it any worse cause the compiler already is allowed to assume that it NEVER can happen " It's the fact that it's UB that allows the compiler to assume it won't happen.
If a project has thousands of functions and each and every one of them can return a failure indication (or throw an exception) no tool can help. Every project should have some basic underling guarantees to reduce the number of failure points first, but it is not happening this way.
Interesting that governments are concerned about "memory safety" while the proposed garbage collected managed or interpreted languages as alternative are a bloated mess killing the climate and increasing the CO2 footprint by wasting CPU and memory.
"Never reads uninitialized memory". Hmm. That's tough. All structs always 1-byte packed, no padding. No SIMD optimized string functions. How about "No outcome ever depends on uninitialized memory"?
The typical way to address this is to ensure that all memory is zero initialized. This is all at the language level of abstraction not the processor, so it is sufficient for the language not to leak information about the content of padding.
@@SeanParent It'll take a while to put all those worms back into the can. Will MSAN still report errors when reading such unintentionally initialized memory?
Ada was designed with safety in mind without minimal impact on performance and resource efficiency. Unlike C++, the programmer just writes Ada code without concerning themselves with how its semantics impacts its execution and size.
Wow. He actually *did* mention the R word at around 24:40. I honestly expected him to continue to carefully talk around the elephant in the room.
Signed integer overflow.... defining that behaviour does not make it any worse cause the compiler already is allowed to assume that it NEVER can happen which means if your code experiences overflow you ALREADY can not do anything about that. Hell because the compiler is allowed to assume it is also allowed to remove ANY AND ALL CODE that tries to check if such an overflow occured.
The one thing this undefined behaviour does it give the compiler a bit more playroom with optimisation.
Worse than just these problems occurring at runtime are the various things that cause "ill-formed no diagnostic required" - aka the compiler can (and mostly does) know that your code is not valid C++ but does not need to tell you and can do whatever bullshit.
" defining that behaviour does not make it any worse cause the compiler already is allowed to assume that it NEVER can happen "
It's the fact that it's UB that allows the compiler to assume it won't happen.
If a project has thousands of functions and each and every one of them can return a failure indication (or throw an exception) no tool can help. Every project should have some basic underling guarantees to reduce the number of failure points first, but it is not happening this way.
Interesting that governments are concerned about "memory safety" while the proposed garbage collected managed or interpreted languages as alternative are a bloated mess killing the climate and increasing the CO2 footprint by wasting CPU and memory.