4

I feel like this is a stupid question, but I have found zero information about the topic (not here nor anywhere), so here's the question:

Context (what you probably already know): SIGFPE exceptions and si_code field

In POSIX/Linux we have a particular kind of signal called SIGFPE (that although its name, it's used both for floating-point and integer arithmetic errors). When we register a signal handler for SIGFPE using sigaction(), our handler also receives a field called si_code that explains why the particular SIGFPE exception has been raised. One of the possible si_code values is, for instance, FPE_INTDIV, and you can quickly test it by dividing an int by 0.

The problem: what about FPE_INTOVF?

My question is about a particular si_code, that is FPE_INTOVF. This code is described as Value signalling integer overflow in case of SIGFPE signal.

The problem is that I have never encountered an example of this signal being raised, nor I found a way to make the OS raise this kind of signal: when I do an integer overflow in C, no SIGFPE exception is thrown. But the FPE_INTOVF value for SIGFPE is a kind of hint that it's maybe possible to make the host throw in case of integer overflows (like it already does for integer division by zero).

The question:

Is FPE_INTOVF unusable? Is it just a place-holder for a type of signal that no POSIX-compliant OS has ever implemented? Or is it possible to instruct the OS to throw this kind of signal in case of integer overflow?

I'm really interested in catching FPE_INTOVF signals from a C program using sigaction().

P.S.: I recognize that unsigned integer overflow is not technically an error in C (it doesn't exist at all in C, since all unsigned integer arithmetic has "wrapping" behavior), but signed integer overflow is indeed undefined behavior, so I expect that FPE_INTOVF handles the latter.

Luca Polito
  • 2,387
  • 14
  • 20
  • 1
    https://elixir.bootlin.com/linux/latest/ident/FPE_INTOVF - alpha ia64 m68k mips parisc s390 superh architectures. `Is FPE_INTOVF unusable?` what do you mean by "unusable"? – KamilCuk Oct 17 '21 at 13:58
  • 2
    AFAIK, Posix defined that `si_code` value for completeness, but you're right, you'll never see it on common processors, since they don't trap on integer overflow at all. – Steve Summit Oct 17 '21 at 14:00
  • 1
    Possibly related: [Compiler flags for checking Integer overflow](https://stackoverflow.com/questions/69104632), [How do I detect unsigned integer multiply overflow?](https://stackoverflow.com/questions/199333) – Steve Summit Oct 17 '21 at 14:01
  • @KamilCuk Interesting, thanks. By the way, by "unusable" I meant that no OS implemented it, so you will never receive a signal of type `FPE_INTOVF`. – Luca Polito Oct 17 '21 at 14:03
  • @SteveSummit I know how to detect overflow with other methods, I was just interested in `FPE_INTOVF` in particular. As KamilCuk found out, it appears that the signal is indeed supported, but only on specific architectures (at least on Linux, I don't know about other POSIX environments). – Luca Polito Oct 17 '21 at 14:05
  • The point is that it needs the CPU to support such exceptions in the first place; it's a hardware feature that may or may not exist depending on the architecture. And the details of exactly when the exception would be raised, and how you enable it, would also be system-specific. It's certainly not going to provide you a nice reliable method for detecting integer overflow in general. `gcc -ftrapv` is probably a better bet for that. – Nate Eldredge Oct 17 '21 at 15:14
  • Another point as far as detecting overflow is that even if the hardware can trap on every possible integer arithmetic instruction that causes overflow (which may or may not be the case), there's also the compiler to consider, which knows that signed integer overflow is UB and might optimize it out, so that no trapping instruction ever gets executed. Again `-ftrapv` would be better because it tells the compiler to define overflow as trapping. – Nate Eldredge Oct 17 '21 at 15:17
  • @NateEldredge Yes, I know about the UB optimization problem, and I have used `-ftrapv` oftentimes. I was just interested in a possible alternative with `FPE_INTOVF` (in the first place, I was just curious, since I've never seen it used in real life). I didn't realize it's too much tied to hardware support. I thought that maybe, with some compiler support, it would work on any CPU. But I think that `FPE_INTOVF` has simply been replaced by `-ftrapv` nowadays and nobody uses it anymore. – Luca Polito Oct 17 '21 at 15:43
  • I'm not sure that the compiler could use `FPE_INTOVF` generically even if it wanted to. It could test every arithmetic operation for overflow, but in case of overflow it can at best `raise(SIGFPE)` and there is no way to specify an `si_code`. I think `si_code` can only come from the hardware, and POSIX just tried to provide constants corresponding roughly to every type of exception they were aware of actual hardware being able to produce, so that some sort of reporting mechanism could exist. – Nate Eldredge Oct 17 '21 at 15:49
  • @NateEldredge FWIW, the host environment could have provided a special raise function so that the compiler may raise a `SIGFPE` specifying its `si_code`. But I guess neither Linux nor other POSIX environments provide such a function (a quick search may confirm my assumption). So yea, `FPE_INTOVF` is definitively meant to be used as a 1:1 mapping to a hardware integer overflow exception. – Luca Polito Oct 17 '21 at 15:55

1 Answers1

4

TL;DR:

Exceptions of type SIGFPE FPE_INTOVF appear to be thrown only when the underlying hardware has support for them. For instance, on Linux, these are the archs that may throw FPE_INTOVF: alpha, ia64, m68k, mips, parisc, s390, and superh.

Not an answer to my question, but worth noting:

My question was about FPE_INTOVF in particular, but if one just wants to check for integer overflow in general, it's worth noting that there are alternative ways to do so: compiler-specific functions like __builtin_sadd_overflow() (read more here) or compiler-specific flags like -ftrapv on GCC. Also see this and this related questions on SO.

Credits

I'd like to thank users KamilCuk, Steve Summit and Nate Eldredge for their contributions to this answer through their comments.

P.S.: in case someone else wants to add other information about FPE_INTOVF, they may post another answer to this question, or they may write a comment to this very answer, and I will edit the answer to add the additional information.

Luca Polito
  • 2,387
  • 14
  • 20