Signals are not exceptions. Languages with exceptions still have to handle signals separately. Signals are an OS construct, and exceptions are a language construct.
To the question of "why not raise a signal on integer overflow in C?" - because signals are a terrible way of dealing with this. The signal handler doesn't know what code caused the overflow, and can't really do anything about it. Once the signal handler returns, the code itself has no idea it caused an overflow. Signals are a way for the OS to send signals to your program and not for control flow, after all. That's why `feenableexcept` is a niche extension that nobody uses.
The standard way of checking for fp errors is by calling `fetestexcept`. Personally I prefer this strategy (doing operation, then checking for errors) vs the new proposal for ints (checking for potential errors before doing the operation). But that is a matter of taste.
Interesting, I've always considered signals to be an exception handling mechanism, as in the 'normal flow' of a program is interrupted and dealt with - or not - through some other mechanism. Learn a new thing every day, even after 40 years of programming in C :) Thanks!
(which has this bit: "C does not have try-catch exception handling, but uses return codes for error checking. The setjmp and longjmp standard library functions can be used to implement try-catch handling via macros.")
Its all semantics, I guess. You could argue that signals can be used to handle exceptional conditions (dereffing NULL). But signals are significantly different than what other programming languages call "exceptions".
Its the same thing as "run time". Pedantically, crt0 exists and therefore C has a "runtime". But it is nothing like what we refer to as a "runtime" today. The literal words are true but the meaning of the words doesn't match expectations.
If C was still just a baby in 1983, what does that make Ada?
Signals were a feature of Unix and C from the early 1970s; at least by 1973, if not earlier. Signals were a software-based abstraction over the concept of hardware interrupts, and even today we often say that hardware interrupts are triggered by (among other reasons) an "exception" or "hardware exception".
Similarly, the fact that the concept of interrupts and exceptions are related can be seen in the later (4.2 BSD, 1983) select(2) syscall, where the third fd_set argument is for capturing "exceptional condition(s)". (https://pubs.opengroup.org/onlinepubs/9699919799/functions/s...)
Ada enjoyed the benefit of at least another 10 years of reflection and evolution in computer science when choosing the semantics of their exception mechanism. But the success of Ada's (or Ada-like) semantics hasn't yet completely redefined the concept of exceptions.
Ada was unobtanium for a long time for mere mortals like myself. In 1983 I was 18 and had access to a C compiler, an Ada compiler would have cost me an arm, a leg and my still to be first born, and information about the language was pretty much limited to what you could get from magazine articles of people that had maybe at some point known someone who had seen an Ada compiler in the wild.
The only other realistic options outside of government/enterprise were Pascal, BASIC and assembler, and within the bulk of the work was done in COBOL.
It's interesting just how far back the mechanism goes even beyond that. Some early structured PLs had non-local computed gotos, which turn out to map pretty close to exceptions, especially on implementation level - the need to unwind the stack etc. Some early papers on implementation even talk about using region maps for a zero-cost non-branching path, similar to the modern approach to C++ exceptions.
To the question of "why not raise a signal on integer overflow in C?" - because signals are a terrible way of dealing with this. The signal handler doesn't know what code caused the overflow, and can't really do anything about it. Once the signal handler returns, the code itself has no idea it caused an overflow. Signals are a way for the OS to send signals to your program and not for control flow, after all. That's why `feenableexcept` is a niche extension that nobody uses.
The standard way of checking for fp errors is by calling `fetestexcept`. Personally I prefer this strategy (doing operation, then checking for errors) vs the new proposal for ints (checking for potential errors before doing the operation). But that is a matter of taste.