That's kind of his point though - don't rely on your intuition for how most common compilers work! Learn enough to write correct code!
/s
My personal gotcha was finding out I was relying on shifting an unsigned integer by the bit size of the integer to be 0, as if "you shifted every bit out of the integer, leaving 0". Shift any size under the integer's size in bits? Yep, those bits were shifted out leaving 0. Shift that last bit? Nope, that's Undefined Behaviour, and suddenly it's not 0 just because you changed a flag.
Most of us would say that it has a value of 32 as defined by ASCII. This would be wrong on a platform that was using EBCDIC.
We all have to make assumptions in our programs, which are sometimes wrong.
RedHat Linux has also been ported to this platform; it's probably ASCII, but not sure.
Oracle has a native client on zOS that does transparent conversion between ASCII and EBCDIC. It was probably built with such a compiler.
There was a paper that the original port of Research UNIX ran as a client on an IBM TSS/370 kernel, which likely was not ASCII.
"So you think you know C, huh? What does this horrible piece of code do that no one would ever write and if you see it should be nuked from orbit? <ridiculous contrived example>"
I just clicked I don't know on all of em, cause I realised what the metagame was from a mile away.
Some of these things are at least a little insightful, but overall, kind of a waste of time past a certain point, unless you work on a compiler or something like that. Much more constructive would be making resources on best practices for things like memory management, string handling, knowing where the footguns are in the stdlib and other common libs, managing complexity etc. Most bad C code isn't because of some standards gotcha, it's because of those things.
But if I'm in an existing codebase, and I see a certain volume of this kind of "potential UB everywhere" code, my first instinct isn't let's spend however long trying to understand what exactly this code may or may not be doing/relying on according to dusty corners of the standard and the datasheet(sometimes you may have to, but I find it's rare). I prefer to approach it as "what is this code supposed to do, and how can it be done more sanely? Usually I find I can replace the crazy code with sane code in a fraction of the time it would take to fully understand the crazy code.