Digging into the mail list from 7 Apr 2009, @rkern writes:

Unlike true floating point errors (where the hardware FPU sets a flag whenever it does an atomic operation that overflows), we need to implement the integer overflow detection ourselves. We do it on the scalars, but not arrays because it would be too slow to implement for every atomic operation on arrays.

I suspect this is still true, and it's too expensive to check on arrays. I suggest improving the numpy.seterr docs to make it clear that number errors can only be detected on scalar types, and not array types.

This is an exact duplicate of #593.

My thoughts were that numpy.seterr was ugly designed. We could make use of some new interface, apart from numpy.seterr, to explicitly define the behavior of integer overflows among choices of

1. to wrap,
2. to raise an exception,
3. to wrap unsigned but raise an exception for signed (Because according to C, unsigned overflow is mandated to wrap, but signed overflow is UB.),

And naming this something like numpy.setintwrap, maybe allow separate settings for scalars and arrays, while replacing numpy.seterr for setfloaterr with no effect on integers.

To do integer overflow right, you need hardware support. Modern hardware does not provide that support. Some ancient hardware did, but it fell out of favor.

Eh, you can do it, it just has some penalty in speed. If we added it for arrays then I think we'd also want to have a dedicated option in seterr (no need to add a separate setintwrap function), and make sure that if errors are disabled then we take a fast-path that disables the checking entirely, so that it actually works as a speed/safety tradeoff knob. All of which seems doable and reasonable to me; integer overflow causes a lot of silent miscalculations.

related to issue pandas-dev/pandas#15557 , issue #5657, issue #5166,

I noticed that numpy.prod overflows silently as well. Not sure if this issue covers that already or if I should open a new issue suggesting an overflow error for that as well.

Looks like the issue is still present with int64.

If I was not using hypothesis given and the integer strategy to test a function I would have not noticed this issue. sum on an array should trigger an overflow signal. please prioritise!

Eh, you can do it, it just has some penalty in speed

Over at #29129 I showed an opt-in path for those who want overflow checking (in this case inside the casting ufuncs used by ndarray.astype). The speed penalty would only be paid by those who opt-in to the check.