Back

When I run it from my default shell, zsh, I get this:

4 % ./segv
zsh: 13512 segmentation fault ./segv

When I run it from bash, I get what you noted in your question:

bediger@flq123:csrc % ./segv
Segmentation fault
#zsh #bash
#Unix signal mechanism is entirely different from the CPU-specific events that start the process.

In general, when a bad address is accessed (or written to a read-only area, attempt to execute a non-executable section, etc.), the CPU will generate some CPU-specific event (on traditional non-VM architectures this was called a segmentation violation, since each "segment" (traditionally, the read-only executable "text", the writable and variable-length "data", and the stack traditionally at the opposite end of memory) had a fixed range of addresses - on a modern architecture it's more likely to be a page fault [for unmapped memory] or an access violation [for read, write, and execute permission issues], and I'll focus on this for the rest of the answer).

Now, at this point, the kernel can do several things. Page faults are also generated for memory that is valid but not loaded (e.g. swapped out, or in a mmapped file, etc.), and in this case the kernel will map the memory and then restart the user program from the instruction that caused the error. Otherwise, it sends a signal. This doesn't exactly "direct [the original event] to the offending program", since the process for installing a signal handler is different and mostly architecture-independent, vs. if the program were expected to simulate installing an interrupt handler.
https://unix.stackexchange.com/questions/257598/how-does-a-segmentation-fault-work-under-the-hood