Avoid narrowing conversion in image_wrapper on 32-bit.

[anntzer]

PR Summary

@yurivict can you check whether that fixes #10698?

PR Checklist

• Has Pytest style unit tests
• Code is PEP 8 compliant
• New features are documented, with examples if plot related
• Documentation is sphinx and numpydoc compliant
• Added an entry to doc/users/next_whats_new/ if major new feature (follow instructions in README.rst there)
• Documented in doc/api/api_changes.rst if API changed in a backward-incompatible way

[yurivict]

Still fails:

src/_image_wrapper.cpp:422:24: error: non-constant-expression cannot be narrowed from type 'unsigned int' to 'npy_intp' (aka 'int') in initializer list [-Wc++11-narrowing]
    npy_intp dim[3] = {rows, cols, 4};
                       ^~~~

[anntzer]

same fix applies there... pushed it

[yurivict]

Now it succeeds, thanks!

[tacaswell]

Just to check, the issue here is that we are implicitly casting a uint -> int which chops off half of the range of the uint and we were probably using uint because the rows / columns should always be positive. Now we are doing the cast explicitly in the PyArg_ParseTuple.

If this was going to cause any issue with the maximum size image we could render, it already would be?

[tacaswell]

Candidate for backport to 2.2.x because this fixes a 'does not compile' bug.

[anntzer]

No, the issue is that (at the npy_intp dim[3] = {rows, cols, 4} line) we were casting an unsigned int (rows) to a npy_intp (intptr_t), which goes from 64bit to 32bit on the OP's architecture (I know this because the ft2 PR had the same issue when I made it work on circleci...), and that's something a compiler is required by the standard to flag (at least with a warning).

Now rows is declared as a npy_intp so everything has the same size. As for PyArg_ParseTuple, the compiler has no knowledge of that function and will happily accept any pointers passed in, but you'll get a crash at runtime if the pointer sizes don't match the format spec. In fact there is indeed an conversion from Py_ssize_t (signed) to npy_intp (unsigned, but at least in practice sizeof(size_t) == sizeof(intptr_t) on all common architechtures nowadays) going on, but that's not something crashing the compiler.

Now that means that yes, if someone passes a negative value for rows, it will be silently wrapped around to a yuge positive value. But in fact the unsigned convertors in PyArg_ParseTuple don't do any overflow checking (https://bugs.python.org/issue33033) so that issue was already present before; the PR actually slightly improves the situation because at least the signed n convertor does overflow checking and we now error cleanly on wildly out-of-range input.