5 ms·
You'd be surprised: Zig has one UB (Undefined Behaviour) that C doesn't have! In release fast mode, unsigned overflow/underflow is undefined in Zig whereas in
by renox 2y ago
You'd be surprised: Zig has one UB (Undefined Behaviour) that C doesn't have!
In release fast mode, unsigned overflow/underflow is undefined in Zig whereas in C it wraps.
:-)
Of course C has many UBs that Zig doesn't have, so C is far less safe than Zig, especially since you can use ReleaseSafe in Zig..
- uecker 2y agoUB is does not automatically make things unsafe. You can have a compiler that implements safe defaults for most UB, and then it is not unsafe.
- ahoka 2y agoBy definition UB cannot be safe.
- marssaxman 2y agothis depends on your choice of definition for "safe"
- Maxatar 2y agoThe definition given by the C standard allows for safe undefined behavior.
- School-Cotton 2y agoSomething can be UB according to the standard, but defined (and safe) according to a particular implementation. Lots of stuff is UB according to the C or C++ standard but does something sensible in gcc and/or clang.
- duped 2y agoThat's implementation defined behavior, not undefined behavior. Undefined behavior explicitly refers to something the compiler does not provide a definition for, including "safe defaults."
- fuhsnn 2y agoCompilers are not prohibited to provide their own definition for UB, that's how UBsan exists.
- Maxatar 2y agoThe C standard says, and I quote: >Possible undefined behavior ranges from ignoring the situation completely with unpredictable results ... or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message) So a compiler is absolutely welcome to make undefined behavior safe. In fact every compiler I know of, such as GCC, clang, MSVC has flags to make various undefined behavior safe, such as signed integer overflow, type punning, casting function pointers to void pointers. The Linux kernel is notorious for leveraging undefined behavior in C for which GCC guarantees specific and well defined behavior. It looks like there is also the notion of unspecified behavior, which gives compilers a choice about the behavior and does not require compilers to document that choice or even choose consistently. And finally there is what you bring up, which is implementation defined behavior which is defined as a subset of unspecified behavior in which compilers must document the choice.
- deleted 2y ago[deleted]
- renox 2y agoWell Zig has ReleaseSafe for this.. ReleaseFast is for using these UBs to generate the fastest code.
- secondcoming 2y agoDoes C automatically wrap? I thought you need to pass `-fwrapv` to the compiler to ensure that.
- greyw 2y agoUnsigned overflow wraps. Signed overflow is undefined behavior.
- kbolino 2y agoThis distinction does not exist in K&R 2/e which documents ANSI C aka C89, but maybe it was added in a later version of the language (or didn't make it into the book)? According to K&R, all overflow is undefined.
- wahern 2y agoI don't have my copy of K&R handy, but this distinction has existed since the initial codification. From C89: 3.1.2.5 Types [...] A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting unsigned integer type. Source: C89 (draft) at https://port70.net/~nsz/c/c89/c89-draft.txt https://port70.net/~nsz/c/c89/c89-draft.txt
- renox 2y ago-fwrapv is for signed integer overflow not unsigned.
- sp1rit 2y agoYes, as unsigned overflow is fine by default. AFAIK the issue was originally that there were still machines that used ones complement for describing negative integers instead of the now customary twos complement.
- deleted 2y ago[deleted]