Catch-23: The New C Standard Sets the World on Fire

Post by pornel » Sun, Apr 02, 2023, 9:46 AM UTC

lionkor wrote: post #153

GuB-42 wrote: post #90

I actually like unreachable() a lot. What it does is that it invokes undefined behavior, that's all. It does nothing trickier than any other kind of UB. In fact, I could implement unreachable() like this: void unreachable() { (char *)0 = 1; }. Standardizing it however gives interesting options for compilers and tool writers. The best use I can find is to bound the values of the argument of a function. For example, if…

Respectfully, you would already be doing this in any C codebase, with `assert()`, right? We are all checking our preconditions with assert... right?

Post by chongli » Sun, Apr 02, 2023, 9:47 AM UTC

adrian_b wrote: post #154

chongli wrote: post #118

Earlier quoted context omitted.

Those things aren’t up to the language, they’re up to hardware. C is a portable language that runs on many different platforms. Some platforms might have protected memory and trap on out of bounds memory access. Other platforms have a single, flat address space where out of bounds memory access is not an error, it just reads whatever is there since your program has full access to all memory. The same goes for integer…

The problem is that here is a vicious circle. Most old computer architectures had a much more complete set of hardware exceptions, including cases like integer overflow or out-of-bounds access. In modern superscalar pipelined CPUs, implementing all the desirable hardware exceptions without reducing the performance remains possible (through speculative execution), but it is more expensive than in simple CPUs. Because…

Post by pjmlp » Sun, Apr 02, 2023, 9:49 AM UTC

eternalban wrote: post #27

C is a very large language masquerading as a small language.

Post by flohofwoe » Sun, Apr 02, 2023, 9:51 AM UTC

benj111 wrote: post #138

codeflo wrote: post #126

Earlier quoted context omitted.

This is not about code that's found to be unreachable through static analysis (where compilers might warn), but about a manual programmer annotation that claims the code is dynamically unreachable even though statically it might look otherwise.

Why would you want that? Is it to aid building for multiple targets? For debug builds?

Post by chongli » Sun, Apr 02, 2023, 10:05 AM UTC

the_why_of_y wrote: post #148

jcranmer wrote: post #99

Earlier quoted context omitted.

> many things that are UB in C/C++ are UB because they are really hard to verify at compile time which makes them almost impossible to program around The second half of the sentence doesn't follow from the first. Take everyone's favorite example, signed integer overflow: all you have to do to avoid UB on signed integer overflow is check for overflow before doing the operation (and C23 finally adds features to do that…

My complaint here is that it took C more than 30 years between defining signed integer overflow as UB and providing programmers with standard library facilities to check if a signed integer operation would result in overflow. I much prefer Rust's approach to arithmetic, where overflow with plain arithmetic operators is defined as a bug, and panics on debug-enabled builds, plus special operations in the standard libra…