Looking at https://www.owasp.org/index.php/Integer_overflow the consequences of integer overflow by itself either crashes/infinite loops. Crashing on overflow is not an improvement in these cases.

To get into exploitable access, you need buffer overflows, which can and should be protected against separately.

Once you protect against buffer overflows, crashing on integer overflows gets you exactly nothing. (Might be OK as an optional, assert-like debugging tool).

> To get into exploitable access, you need buffer overflows, which can and should be protected against separately.

Or you can use overflow to make the program to allocate too small buffer thus obtaining the buffer overflow you need to proceed further.

You're not making any sense: I already wrote "protect against buffer overflow instead of integer overflow" and your response is "buffer overflow".

Integer overflow can be a causal cause of buffer overflow. Like this for example:

  read(fd, &header, sizeof(header));
  int total_len = header.data_len + header.code_len;
  char *data = malloc(total_len);
  read(fd, data, total_len);

Now, the attacker crafts the file and.. there's your buffer overflow which is a direct consequence of undetected integer overflow [i.e., the program being allowed to proceed].

Once again: if you protect against buffer overflow, an integer overflow that might lead to buffer overflow doesn't matter. The C example doesn't matter because C has neither.