4 ms·

"Carefully chosen undefined behavior. For example, in Zig both signed and unsigned integers have undefined behavior on overflow, contrasted to only signed integ

"Carefully chosen undefined behavior. For example, in Zig both signed and unsigned integers have undefined behavior on overflow, contrasted to only signed integers in C. This facilitates optimizations that are not available in C. " Whoa, whoa, whoa. UB on unsigned!? Best of luck.

xandroo 6y ago
It’s checked in debug modes (overflow is a runtime error). You can explicitly use the overflow operator (+%) if you know that’s the behavior you want.
- jedisct1 6y ago
  In ReleaseSafe mode, too.
- secondcoming 6y ago
  Fine, but the bugs this will cause when people port code across from C or C++... probably painful. So, to be safe people should build both Debug and Release?
  - jedisct1 6y ago
    Develop in debug mode, deploy in safe release mode, and when you're absolutely sure that everything is safe, you can switch to the fast release mode. It is also possible to selectively disable/enable safety for individual code blocks.
  - dnautics 6y ago
    It's going to be a real strategy to write your code in releasesafe, identify hot code, and mark it off as releasefast on a function by function basis
  - xandroo 6y ago
    Alternatively, there may be unfound overflow bugs in that C/C++ code. Worth noting that UB is also checked in ReleaseSafe mode. Related issue: https://github.com/ziglang/zig/issues/2301 https://github.com/ziglang/zig/issues/2301
    - secondcoming 6y ago
      Only with signed ints, since unsigned overflow is defined behaviour.
  - gameswithgo 6y ago
    probably deploy in saferelease mode always unless you are making something like a single player video game, or that otherwise has incredible performance needs but does not deal with untrusted data.
dnautics 6y ago
There's slightly different looking operators if you want explicit overflow behaviour, where it's not UB.
- Gibbon1 6y ago
  I keep coming back to the idea that you should let the user decide. And optimizing on UB by default is always the wrong thing. Because for 99% of code performance is secondary to correctness. The compiler should only do that when requested. A point: Benchmarks produce metrics measured in seconds. Bugs don't produce metrics you can measure but the costs are unbounded.
  - simias 6y ago
    >I keep coming back to the idea that you should let the user decide. And optimizing on UB by default is always the wrong thing. Aren't you contradicting yourself here? And I do think that some UB optimizations make a lot of sense. Actually if you look at the way Rust does it, it gets rid of many UBs not by adding checks for them but by explicitly forbidding the UB condition to occur in safe code (therefore "optimizing on UB" by enforcing that the UB condition cannot happen in correct code, not by adding checks for it and slowing things down). That's why for instance pointer arithmetic is unsafe in Rust, since arbitrary pointer offsets can lead to UB. Although I agree that there are a few C UBs that I think ought to be relaxed because they don't make a lot of sense for modern architectures though (signed overflow being the main one).
    - Gibbon1 6y ago
      I just draw on firmware that I write for micro-controllers. Most of the code isn't in a hot path. There is probably 100 lines worth out of 50,000. That's what I mean by optimizing on UB by default at least in my case seems wrong. I'm also in the apposite situation from a web service where if a worker thread hangs you just kill it and restart it. And you can push update to the cloud. Bringing up signed overflow. I did some tests once flipping back and forth between using a int and an unsigned int and wasn't impressed with the speed up. I've also done tests with aligned and an packed data structures and on a modern processor, also not impressed.

xandroo 6y ago

It’s checked in debug modes (overflow is a runtime error). You can explicitly use the overflow operator (+%) if you know that’s the behavior you want.

jedisct1 6y ago
In ReleaseSafe mode, too.
secondcoming 6y ago
Fine, but the bugs this will cause when people port code across from C or C++... probably painful. So, to be safe people should build both Debug and Release?
- jedisct1 6y ago
  Develop in debug mode, deploy in safe release mode, and when you're absolutely sure that everything is safe, you can switch to the fast release mode. It is also possible to selectively disable/enable safety for individual code blocks.
- dnautics 6y ago
  It's going to be a real strategy to write your code in releasesafe, identify hot code, and mark it off as releasefast on a function by function basis
- xandroo 6y ago
  Alternatively, there may be unfound overflow bugs in that C/C++ code. Worth noting that UB is also checked in ReleaseSafe mode. Related issue: https://github.com/ziglang/zig/issues/2301 https://github.com/ziglang/zig/issues/2301
  - secondcoming 6y ago
    Only with signed ints, since unsigned overflow is defined behaviour.
- gameswithgo 6y ago
  probably deploy in saferelease mode always unless you are making something like a single player video game, or that otherwise has incredible performance needs but does not deal with untrusted data.

dnautics 6y ago

There's slightly different looking operators if you want explicit overflow behaviour, where it's not UB.

Gibbon1 6y ago
I keep coming back to the idea that you should let the user decide. And optimizing on UB by default is always the wrong thing. Because for 99% of code performance is secondary to correctness. The compiler should only do that when requested. A point: Benchmarks produce metrics measured in seconds. Bugs don't produce metrics you can measure but the costs are unbounded.
- simias 6y ago
  >I keep coming back to the idea that you should let the user decide. And optimizing on UB by default is always the wrong thing. Aren't you contradicting yourself here? And I do think that some UB optimizations make a lot of sense. Actually if you look at the way Rust does it, it gets rid of many UBs not by adding checks for them but by explicitly forbidding the UB condition to occur in safe code (therefore "optimizing on UB" by enforcing that the UB condition cannot happen in correct code, not by adding checks for it and slowing things down). That's why for instance pointer arithmetic is unsafe in Rust, since arbitrary pointer offsets can lead to UB. Although I agree that there are a few C UBs that I think ought to be relaxed because they don't make a lot of sense for modern architectures though (signed overflow being the main one).
  - Gibbon1 6y ago
    I just draw on firmware that I write for micro-controllers. Most of the code isn't in a hot path. There is probably 100 lines worth out of 50,000. That's what I mean by optimizing on UB by default at least in my case seems wrong. I'm also in the apposite situation from a web service where if a worker thread hangs you just kill it and restart it. And you can push update to the cloud. Bringing up signed overflow. I did some tests once flipping back and forth between using a int and an unsigned int and wasn't impressed with the speed up. I've also done tests with aligned and an packed data structures and on a modern processor, also not impressed.