back
12 comments
"Unlike higher-level languages, the C standard does not define any checks that could detect such erroneous accesses ["buffer overflows, NULL pointer dereferences, and use-after-free errors"] and then abort the program."

Stephen Kell, in "Some Were Meant for C: The Endurance of an Unmanageable Language", writes a simple and fairly strong argument that, for C, that's not a valid complaint. Since C is a systems language, the proper place to look for those (particularly runtime) checks is in the combination of the C standard and the system it's running on, particularly the hardware.

Edit: "Compiler optimizations can lead to false positives . For example, a false positive that was found in an ASan-instrumented Firefox build was caused by load-widening [55] where a series of loads is transformed into a single load of several memory values at once while potentially exceeding the bounds of an object. Due to platform-specific alignment requirements, such an optimization can be correct at the system level; however, ASan classified it as a bug because the access would be out of bounds in C."

Yep, there we go.

Systems languages looked quite different in what it meant to be unsafe before C took the keys of the kingdom.
Right. I think a lot of people forget that C wasn’t (and isn’t!) the only systems language that was in heavy usage, and indeed a lot of its predecessors and contemporaries were much safer. But hey, worse is better, and C won, so I’m fighting a losing battle here I think.
> "Unlike higher-level languages, the C standard does not define any checks that could detect such erroneous accesses ["buffer overflows, NULL pointer dereferences, and use-after-free errors"] and then abort the program."

Actually C11 Annex K does. It's just that it is ignored because it came from Microsoft.

Tl;dr: They created a run-time bug finder similar to valgrind by creating a LLVM IR interpreter in Java. It finds bugs and is much faster than valgrind (which is a win). They go on with:

"In this paper, we have presented a novel bug-finding tool for C programs that is based on abstraction of the underlying machine. We implemented our approach in a tool called Safe Sulong, which discovered several errors in open-source projects that current bug-finding tools could not find. By using dynamic compilation, Safe Sulong reaches a peak performance that is comparable to that of Clang -O0 , and even that of Clang -O3 in some cases."

Sounds like it may have similar coverage to tis-interpreter ( https://trust-in-soft.com/tis-interpreter/ ), but significantly faster.
The idea is reminiscent of Miri for Rust: https://github.com/solson/miri
"we implemented a libc that is written in standard C and does not rely on any GNU extensions."

Does anyone know if such library is available somewhere?

http://www.musl-libc.org although it may not be absolutely 100% that way.

From the FAQ:

> When building musl, you will also need a C99 compiler with support for gcc-style __asm__ statements and assembly source files, and weak symbol support in the linker. gcc 3.3 or later (with the GNU assembler and linker) and clang 3.2 or later are known to work.

Sorry, I meant their libc. That would be very useful if open-sourced.

They state that "we provide our own libc that is written in standard C and is optimized for safety instead of performance", but I don't see where to find it.

The bounds checks, null and zero checks are also in safeclib, which is written in pure C99 without asm, getting the same speed as glibc on clang-7.

https://github.com/rurban/safeclib on top of an existing unsafe libc, if glibc, bsd, musl or windows msvcrt/ulibc.

Whoa, dolphins are so smart.