BUG: fix integer size confusion in handling array's ndmin argument

[mwhudson]

The ndmin local variable was changed from an "int" to an "npy_intp" but
&ndmin is passed to PyArg_ParseTupleAndKeywords against a "i" argument
spec, but these integers have different sizes (well on an LP64 platform
anyway). This actually works on a little endian system but fails
on a big endian one. Fix this by converting the local back to an int,
and being a little careful before assigning the result of PyLong_AsLong to
it.

Fixes #14767

[eric-wieser]

Did the numpy test suite pass on the machine you ran into this on? If so, can we add a test that would fail?

[mwhudson]

Did the numpy test suite pass on the machine you ran into this on?

You mean before this change? No, not even close.

If so, can we add a test that would fail?

I don't think it's possible to write a test that will fail on a little endian system. I also can't think of an easy way to run CI on a big endian system. You might be able to get access to s390x via https://developer.ibm.com/linuxone (or by finding the right person inside IBM, I guess), or run some simple tests via qemu system emulation or something,

[awilfox]

Big endian CI can be done on POWER9 (which is ppc64); there is Integricloud for a VPS, but I'll poke some people.

[xnox]

@awilfox POWER9 is ppc64le, meaning little-endian. I don't believe there are any active distributions with ppc64 (64bit big endian ports).

[awilfox]

@awilfox POWER9 is ppc64le, meaning little-endian. I don't believe there are any active distributions with ppc64 (64bit big endian ports).

That's not true; POWER9 is bi-endian. FreeBSD, Gentoo, Adélie, Void all have big endian ports that run natively on POWER9.

[mattip]

While in theory big endian exists for POWER9, it is difficult to find a CI service that provides that variant. Even the gcc build farm offers only little-endian POWER9 machines. I think the only little-endian machine on that list is mips64.

[sharkcz]

Yes, CI as a service is difficult for big endian arches, but having access to big endian machines isn't. Hope the CI situation will change some time.

[xnox]

Compiler warnings and static analysis should be able to detect this issue, with lots of noise.

numpy/core/src/multiarray/multiarraymodule.c:1654:25: warning: conversion from ‘long int’ to ‘int’ may change value [-Wconversion]
numpy/core/src/multiarray/multiarraymodule.c:2469:42: warning: conversion from ‘int’ to ‘char’ may change value [-Wconversion]
numpy/core/src/multiarray/multiarraymodule.c:2472:42: warning: conversion from ‘int’ to ‘char’ may change value [-Wconversion]
numpy/core/src/multiarray/multiarraymodule.c:2584:12: warning: conversion from ‘npy_intp’ {aka ‘long int’} to ‘int’ may change value [-Wconversion]
numpy/core/src/multiarray/multiarraymodule.c:3665:26: warning: conversion from ‘Py_ssize_t’ {aka ‘long int’} to ‘int’ may change value [-Wconversion]
numpy/core/src/multiarray/multiarraymodule.c:644:15: warning: conversion from ‘Py_ssize_t’ {aka ‘long int’} to ‘int’ may change value [-Wconversion]

numpy/core/src/multiarray/multiarraymodule.c:1257:54: warning: conversion to ‘size_t’ {aka ‘long unsigned int’} from ‘int’ may change the sign of the result [-Wsign-conversion]
numpy/core/src/multiarray/multiarraymodule.c:1264:30: warning: conversion to ‘size_t’ {aka ‘long unsigned int’} from ‘npy_intp’ {aka ‘long int’} may change the sign of the result [-Wsign-conversion]
numpy/core/src/multiarray/multiarraymodule.c:1265:30: warning: conversion to ‘size_t’ {aka ‘long unsigned int’} from ‘npy_intp’ {aka ‘long int’} may change the sign of the result [-Wsign-conversion]
numpy/core/src/multiarray/multiarraymodule.c:1266:30: warning: conversion to ‘size_t’ {aka ‘long unsigned int’} from ‘npy_intp’ {aka ‘long int’} may change the sign of the result [-Wsign-conversion]
numpy/core/src/multiarray/multiarraymodule.c:1915:43: warning: conversion to ‘size_t’ {aka ‘long unsigned int’} from ‘int’ may change the sign of the result [-Wsign-conversion]
numpy/core/src/multiarray/multiarraymodule.c:1919:40: warning: conversion to ‘size_t’ {aka ‘long unsigned int’} from ‘int’ may change the sign of the result [-Wsign-conversion]
numpy/core/src/multiarray/multiarraymodule.c:250:42: warning: conversion to ‘long unsigned int’ from ‘npy_intp’ {aka ‘long int’} may change the sign of the result [-Wsign-conversion]
numpy/core/src/multiarray/multiarraymodule.c:263:49: warning: conversion to ‘long unsigned int’ from ‘npy_intp’ {aka ‘long int’} may change the sign of the result [-Wsign-conversion]
numpy/core/src/multiarray/multiarraymodule.c:277:42: warning: conversion to ‘long unsigned int’ from ‘int’ may change the sign of the result [-Wsign-conversion]
numpy/core/src/multiarray/multiarraymodule.c:3231:34: warning: conversion to ‘long unsigned int’ from ‘npy_intp’ {aka ‘long int’} may change the sign of the result [-Wsign-conversion]
numpy/core/src/multiarray/multiarraymodule.c:3552:54: warning: conversion to ‘int’ from ‘unsigned int’ may change the sign of the result [-Wsign-conversion]
numpy/core/src/multiarray/multiarraymodule.c:409:50: warning: conversion to ‘long unsigned int’ from ‘int’ may change the sign of the result [-Wsign-conversion]
numpy/core/src/multiarray/multiarraymodule.c:648:37: warning: conversion to ‘long unsigned int’ from ‘int’ may change the sign of the result [-Wsign-conversion]

However, not all of them are true issues, as they depend on actual ranges of source and target values and endianness....

I wonder if it might be sufficient to cross-compile to a big-endian target with these options on to spot issues.

[eric-wieser]

Compiler warnings and static analysis should be able to detect this issue

I don't agree. The compiler is powerless when it comes to checking the types in va_list functions beyond a printf - and the python API has lots of those, one of which is the one to blame here.

[xnox]

Compiler warnings and static analysis should be able to detect this issue

I don't agree. The compiler is powerless when it comes to checking the types in va_list functions beyond a printf - and the python API has lots of those, one of which is the one to blame here.

True.... we can ask cpython to write gcc-plugin to add those in a similar fashion as printf warnings?

[eric-wieser]

That would certainly be cool

The path I was considering was trying to write my own semmle QL query for LGTM.com, using their printf example to go by.

[xnox]

I think I don't understand the issue correctly here:

We call

long PyLong_AsLong(PyObject *obj)

and assign the result to int which is broken, as we should be assigning result to long. So why can't compiler catch this? Given that PyLong_AsLong is a normal exported C function.

[eric-wieser]

@xnox: while you're right that that's sloppy, that's not the cause of the issue. The problem is we call PyArg_ParseTuple("i", &some_long), but i expects int*.

[mattip]

The PR in question looks ready. We can put this in and continue to look for more systematic solutions. I will merge soon unless there is more review.

[eric-wieser]

Test failure looks unrelated, will restart it to be sure

[mattip]

Something is up with azure, restarting tests doesn;t seem to work. Is there a reason not to merge this now (I let it slip before)?

[eric-wieser]

If we're fine dealing with the likely unrelated azure problem later,I see no reason not to merge

[mattip]

Thanks @mwhudson