Well some aspects are still not clear. If this thing was originally called "segmentation violation", who, when switched to calling it "segmentation fault"? Why we don't get<p><pre><code> Segmentation violation (core dumped)
</code></pre>
when this thing fires?<p>Actually "violation" sounds much clearer to me. It's telling me that the code I'm running does something that was not part of the contract. With "fault"... well, it's someone's fault... probably someone else's fault... who knows what happened... ¯\_(ツ)_/¯<p>I wouldn't be surprised if it was found out to sound smoother to managerial ears.
On a BBS forum in the 90s, I read some lyrics for a blues song where each verse ended with "segmentation violation -- core dumped blues". Here is what seems to be the definitive version of that song:<p><a href="https://www.netfunny.com/rhf/jokes/92q3/coredb.html" rel="nofollow">https://www.netfunny.com/rhf/jokes/92q3/coredb.html</a>
The author makes a big fuss about the old UNIX documentation using sigseg instead of sigsegv.. but then completely ignores the comment in the same line that does use the word violation
It's interesting to see all signal names in that early version had six letters (SIGQIT instead of SIGQUIT, even) but SIGPIPE was the exception. Was that one added later?<p>(Also funny how the article says "this is from around 1978" when the date on the listing says May 24 1976)
I started a project similar to the fictional "skip instructions that cause segmentation violations" for SIGILL (illegal instruction) which tried to implement SSE3 replacements on hosts without SSE3. It had two modes: replace the illegal instruction in memory, or handle it in the signal handler:<p><a href="https://github.com/rkeene/sse3-emu" rel="nofollow">https://github.com/rkeene/sse3-emu</a>
The original cited SIGSEG constant definition in the OP still has a "segmentation violation" right there in the comment. Which suggests that "violation" was the norm even then.