For 8 and 3, I believe you're right (That's what I was thinking too - undefined-behavior), but I think they're making some type of distinction between UD and a undefined value/result. In C right now, there isn't any guarantee your code will actually keep going since it's UD, with an 'undefined value' I presume it means you still get some type of number and your code keeps going with that bad number (Which may or may not have bad consequences. I'm not really sure this is better then just UD, but most implementations just give you whatever random value was there anyway so it wouldn't really change much besides guaranteeing your code will run with a bad value instead of the compiler blowing up on the UD).

As for 4, I was also curious on that. I think they're just trying to specify something more specific then UD, like a SIGSEGV (or whatever signal thing Windows does). Compilers basically do that already though, and any architecture that doesn't do some type of trap on an invalid pointer probably doesn't have the infrastructure to do so. That said, the biggest issue is not what the trap is, but how the trap is caught or handled. It's not really that helpful of a standard if you know it's going to "trap", but you have no standard way of handling such a trap.