Did you know that py::buffer_info::format has a different meaning on Windows?

On Windows (both 32-bit and 64-bit Python),

std::string f(py::array a) {
    py::buffer_info info = a.request();
    return info.format;
}

returns "l" for a numpy.int32 array and "q" for a numpy.int64 array, whereas MacOS and Linux return "i" and "l", respectively. (That is, "l" is ambiguous.)

To be safe against misinterpretations, I'm using

auto b = a.cast<py::array_t<int64_t, py::array::c_style | py::array::forcecast>>();

to convert whatever I have into int64_t (and similarly for int32_t), if necessary. (Then, choosing int32_t vs int64_t based on platform is just an optimization, not needed for correctness.)

Start by reproducing the py::buffer_info::format results for NumPy int32 and int64 arrays on Windows, then compare them with the stated macOS and Linux results. The issue mentions py::array::request(), py::array_t, and forcecast; done should establish the intended cross-platform format behavior and whether the discrepancy needs a code or documentation change.