[SciPy-dev] Changing return types in C API

[David M. Cooke]

Travis Oliphant <oliphant at ee.byu.edu> writes:

> David M. Cooke wrote:
>
>>Sasha <ndarray at mac.com> writes:
>>  
>>
>>I'll look for those. One trouble is the strides member of
>>PyArrayObject; it's harder by a bit to apply a stride given in bytes
>>to a double * (say). Although this is the same problem that you'd have
>>after casting from the char* to the double *.
>>  
>>
>
> This is the real trouble.  The reason data is a char* is because strides 
> is given in bytes.  If we were to change the meaning of strides to 
> "elements",  this would break a lot of code that assumes it is given in 
> bytes.
>
> Also, there is much more flexibility when strides can be given in terms 
> of bytes.  You can define a record with
> float, int16 elements, and now the float array can also be defined 
> easily using strides.  Of course it is a misaligned array, but that is 
> the point of the ALIGNED flag...

Hmm..

Ok, how about this? Change the definition of PyArray_DATA to

#define PyArray_DATA(obj) ((void *)(((PyArrayObject *)(obj))->data))

(i.e., throw in an explicit void * cast). If you're assigning to a
char *, this will still work for bytes.  If you're dereferencing it,
the compiler should throw an error. Also, introduce

#define PyArray_BYTES(obj) (((PyArrayObject *)(obj))->data)

when you actually want the byte-based version.

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke                      http://arbutus.physics.mcmaster.ca/dmc/
|cookedm at physics.mcmaster.ca