[Numpy-discussion] fwrite() failure in PyArray_ToFile

[David Cournapeau]

On Sat, Sep 5, 2009 at 2:01 PM, Charles R
Harris<charlesr.harris at gmail.com> wrote:
>
>
> On Fri, Sep 4, 2009 at 10:29 PM, Sturla Molden <sturla at molden.no> wrote:
>>
>> Charles R Harris skrev:
>> > The size of long depends on the compiler as well as the operating
>> > system. On linux x86_64, IIRC, it is 64 bits, on Windows64 I believe
>> > it is 32. Ints always seem to be 32 bits.
>> If I remember the C standard correctly, a long is guaranteed to be at
>> least 32 bits, whereas an int is guaranteed to be at least 16 bits. A
>> short is at least 16 bits and a long long is 64 bits. Then there is
>> intptr_t which is wide enough to store a pointer, but could be wider. A
>> size_t usually has the size of a pointer but not always (on segment and
>> offset architectures they might differ). Considering PEP353, should we
>> be indexing with Py_ssize_t instead of npy_intp? I believe (correct me
>> if I'm wrong) npy_intp is typedef'ed to Py_intptr_t.
>>
>
> The problem is that Py_ssize_t showed up in Python 2.5 and we support 2.4.
> For earlier versions folks usually typedef Py_ssize_t to int, which works
> for python compatibility but would cause problems for us if we used it as
> the npy_intp type.

We could use our own npy_ssize_t, though. I find npy_intp for indexing
quite confusing. I have started a patch toward this during the scipy09
sprints. There are a lot of bogus loops in numpy and scipy where the
indexing loop is an int BTW.

For the formatting, we should have our own formatting macro to deal
with printing those -  I have meant to implement them, but it is a bit
of work to do it correctly as a printf format for size_t only appeared
in C99 (the usual workaround to use usigned long is wrong on windows
64).

cheers,

David