Re:Zig's New Relationship with LLVM
by setpatchaddress on Monday September 28, 2020 @12:36PM
(#24618482)
They are very effective, but relatively difficult to use.
[ Parent
| on HN ]
They're built into both GCC and Clang and very easy to use IMO.
The only hard part is figuring out how to pass -fsanitize=address into your compiler via your complex build system! And building with symbols.
That is inherent to the C/C++ toolchain and not a problem that sanitizers can address.
Just to be clear, Zig isn't the same as C/C++ with sanitizers. Zig has slices and it doesn't have pointer arithmetic and pervasive casts. For example, if you preallocate a buffer and then reuse it, or chunk it into multiple pieces, sanitizers won't find an issue, but Zig will (thanks to slices). C simply has no way to express, "I want to pass a pointer into an array to this subroutine but it is only allowed to use n elements," when n is dynamic.
C++ has it though, https://github.com/microsoft/GSL/blob/master/include/gsl/spa...
Right, but in this case it's not a matter of what you have, but what you don't. Zig has slices as the only form of moving pointers around, and it doesn't have any pointer arithmetic. I.e. every time some data is traversed, the language ensures the size is known either at compile time or runtime.
For the time being, https://github.com/ziglang/zig/issues/2018
This isn't exactly pointer arithmetic as in C (or in unsafe Zig, as with @intToPtr, or using the "unknown size" pointer type, [*]). This is talking about preserving size information, and only when the arithmetic is compile-time-known; so it's more "array arithmetic".
Fair enough.
Sure but a language where "the only hard part" isn't a factor surely has a leg up on one where it is.
A lot of the advantage which Zig has over C is exactly in not having to support a towering edifice of tools and hacks which is older than I am. This is true to a significant degree of Rust and C++ as well.