On 1/10/2023 10:49 PM, Siarhei Siamashka wrote:
It's impractical to have this in the ISO standard, but surely not impossible.
Various C compilers from different vendors implement bounds checking. See:
* https://bellard.org/tcc/tcc-doc.html#Bounds
This works by constructing a data structure of all the allocated memory, and
then comparing a pointer dereference to see if it's pointing to valid data. It
sounds like what valgrind does. It's very slow, and wouldn't be used in a
shipped executable, like you wouldn't ship valgrind. It's vulnerable to memory
corruption when your app gets tested with inputs that were never tested when
this checking was turned on.
* https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html
Adds a bunch of runtime checks you wouldn't want to ship an executable with them
turned on.
* https://clang.llvm.org/docs/AddressSanitizer.html
Same problem. 2x slowdown, won't use it in shipped executable.
*
https://learn.microsoft.com/en-us/visualstudio/debugger/how-to-use-native-run-time-checks?view=vs-2022
Not really clear what this does.
So your statement that "C has no mechanism to prevent them" just ignores reality
and the existing C compilers. If you are comparing the lowest common denominator
ISO C spec with the vendor specific DigitalMars D implementation, then this is
not a honest apples-to-apples comparison.
They all seem to have the same problem - they are only useful when the program
is under test. When the program is shipped, they're not there.
The Linux kernel is using GNU C compiler and recently switched from `-std=gnu89`
to `-std=gnu11`.
Bounds checking in the Linux kernel is done by
https://docs.kernel.org/dev-tools/kfence.html or
Being sampling based, this is not good enough.
https://docs.kernel.org/dev-tools/kasan.html
Another test-only tool.
Please don't misunderstand me, these tools are good. But they have really
nothing to do with the C language specification (which is completely unhelpful
in resolving this issue), have too high overhead to be useful in a shipped
product, and have not stopped C from having buffer overflows being the #1 bug in
shipped software.
I stand by the idea that C's semantics make it impossible. These tools are all
things layered on top of C, and they certainly help, and I would use them if I
was developing in C, but they simply do not solve the problem.
