*(char*)0 = 0; - What Does the C++ Programmer Intend With This Code?
summary
Simple program (char)0 = 0; provokes lots of specific behaviors: compilers optimize or trap (for example clang -O2 drops it while GCC sometimes inserts a trap), std::bit_cast diagnostics differ from __builtin_bitcast, and changing 0 to -0 can silence a front‑end check. Experiments compile and run into SIGSEGV on many OSes; emulation and tooling (GDB, valgrind/Cachegrind, QEMU) reproduce hardware effects. The code surfaces undefined behavior, page‑table/TLB interactions, and mismatches between language intent, compiler diagnostics, and real hardware.
AI-written summary · about
chapters (15)
- 0:00Introduction
- 1:27Interview question context
- 5:18Code breakdown and null deref
- 9:08C++ rewrite and compiler errors
- 17:40Fixing and running code
- 22:21Code behavior perspectives
- 26:12Objects, memory mapping, hardware
- 28:20Memory protection and mapping
- 33:30Page tables and lookups
- 40:12How caches speed memory
- 43:02TLBs and cache hierarchy
- 49:00Debugging and simulation
- 51:03Code meaning and specs
- 52:48Human side of low-level
- 53:29Closing remarks
related talks
01h 04mRemoving Needless Undefined Behavior for a Safer C++
05mDetecting Programs That Rely on Undefined Behavior
01h 28mProgramming in Modern C with a Sneak Peek into C23
05mFighting Compiler warnings
01h 27mDangerous Optimizations! in C++ - Part Deux
56mWhat Do We Mean When We Say Nothing At All?
05mThe dangers of C-style casts
49mUndefined Behavior in 2017 (part 1 of 2)
