See also #7813 (comment)

Oh, is this a new bug or an old? Oh well, probably does not matter. I think it is supposed to allocate a single element for these arrays, though even that should really be unnecessary.

@seberg Old. There is a comment in the code that some memory is needed:

        /*
         * Allocate something even for zero-space arrays
         * e.g. shape=(0,) -- otherwise buffer exposure
         * (a.data) doesn't work as it should.
         */

But that path is never taken currently. I'll put up a patch.

See #7820.

If someone will review #7820 and #7817 I'll try to get a 1.11.2rc1 out tomorrow.

hm there is nothing worth releasing on the branch, why the rush?
this issue is super unimportant

There is also a fix for a failing test in pending scipy release.

@juliantaylor See #7515. However, the release schedule is negotiable.

#7813 causes scipy.test() to crash on 32 bit Python 2.6-3.4 for Windows. That's how I discovered the issues.

Thanks for the fix and backport @charris.

Still, I would not expect numpy.zeros((0, 2**31-1)) to raise ValueError: array is too big; arr.size * arr.dtype.itemsize is larger than the maximum possible size. on 32 bit but that is a different issue.

Well, it is a bit of a theoretical construct and there are some things (like stride/size after view) which may misbehave. So I think it is correct to just disallow it. I admit the error message might be a bit confusing in this specific case.
However, I doubt there is any reason to have a (0, huge) array in a place where a (1, huge) array can never occur, so it also seems unlikely for anyone to run into it, unless when designing weird tests or just trying out edge cases for fun.