[PATCH] Clarify English strsignal() messages.

[Zack Weinberg]

On Wed, Sep 24, 2025, at 4:08 AM, Florian Weimer wrote:
> * Zack Weinberg:
>> “Floating point exception” -> “Arithmetic exception”:
>>   Nowadays SIGFPE is almost always caused by *integer* divide by zero,
>>   since ISO C says the floating point environment at program startup
>>   has trapping disabled for all exceptions (C2011: Annex F subsection 8.3).
>>   When I was teaching CS I regularly got questions from students about
>>   why they got this error message when their program didn’t use any
>>   floating point at all.  “Arithmetic exception” is the phrase used by
>>   musl libc, and also by the entire Sun clade for many years.
>
> But is “exception” really the right term here?  Language-level
> exceptions don't result in signals.

I'm not attached to the word.  It's used by two other C libraries and
by IEEE 754 (and thus <fenv.h>), but I don't feel that's a strong
argument.  None of the other synchronous CPU-triggered signals use
"execption" ...

SIGBUS    -> "Bus error"
SIGSEGV   -> "Segmentation fault"
SIGSTKFLT -> "Stack fault"

SIGEMT    -> "CPU emulation trap"       (was "EMT trap")
SIGILL    -> "Invalid CPU instruction"  (was "Illegal instruction")
SIGTRAP   -> "Trace/breakpoint trap"

SIGFPE    -> "Arithmetic exception"     (was "Floating point exception")

... however, SIGFPE _is_ in a class of its own.  The others either
indicate a memory access error (SIGBUS, SIGSEGV, SIGSTKFLT),
a machine instruction that the CPU cannot execute (SIGEMT, SIGILL),
or a machine instruction whose sole function is to cause a hardware
trap (SIGTRAP).  SIGFPE indicates neither of those things; it means
the mathematical result of an arithmetic operation is either
undefined or unrepresentable.

We are _almost_ consistently using the word "fault" for memory access
errors, and "trap" for troublesome machine instructions.  I don't
think we should reuse either for SIGFPE.  "Invalid arithmetic operation"
would be clearer for integer divide by zero and also for _some_ IEEE 754
exceptions, but not for FE_{INEXACT,UNDERFLOW,OVERFLOW} conditions.
"Undefined or unrepresentable arithmetic result" would be exact but is
a bit too much of a mouthful.

I dunno.  Does anyone else have an opinion?

(I'm hesitant to change SIGBUS, but making it be "Bus fault" would
mean that we _consistently_ used "fault" for memory access errors.)

>> “Illegal instruction” -> “Invalid CPU instruction”
>>   I vaguely recall something in the GNU coding standards about
>>   preferring “invalid” to “illegal” unless something is actually
>>   against the law.  Indicate what kind of instructions are meant.
>
> It's not necessarily an invalid instruction.  Several architectures
> have an instruction that is defined to produce this signal.

I don't think that's a strong argument.  "The ISA defines an
instruction whose effect is to trigger the invalid-instruction trap"
is not meaningfully different from "the ISA defines an instruction-like
bit pattern that is permanently reserved and will never be a valid CPU
instruction".

zw