[Cython] new arrayarray.h header file not C99 compatible

[Robert Bradshaw]

On Mon, Aug 20, 2012 at 9:10 AM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Robert Bradshaw, 20.08.2012 17:54:
>> On Mon, Aug 20, 2012 at 6:39 AM, Stefan Behnel wrote:
>>> I'm getting test build failures with the new arrayarray.h header file when
>>> I enable "--std=c89" or "c99" in the CFLAGS:
>>>
>>> """
>>> memoryview_inplace_division.c:877: warning: declaration does not declare
>>> anything
>>> memoryview_inplace_division.c:893: warning: declaration does not declare
>>> anything
>>> memoryview_inplace_division.c: In function ‘newarrayobject’:
>>> memoryview_inplace_division.c:929: error: ‘arrayobject’ has no member named
>>> ‘ob_item’
>>> ...
>>> """
>>>
>>> The lines it warns about (and which trigger the subsequent errors) are the
>>> following union declarations:
>>>
>>> """
>>> typedef struct arrayobject {
>>>     PyObject_HEAD
>>>     union {
>>>         Py_ssize_t ob_size, length;
>>>     };
>>>     union {
>>>         char *ob_item;
>>>         float *_f;
>>>         double *_d;
>>>         int *_i;
>>>         unsigned *_I;
>>>         unsigned char *_B;
>>>         signed char *_b;
>>>         char *_c;
>>>         unsigned long *_L;
>>>         long *_l;
>>>         short *_h;
>>>         unsigned short *_H;
>>>         Py_UNICODE *_u;
>>>         void *_v;
>>>     };
>>> ...
>>> """
>>>
>>> Apparently, anonymous unions only became part of the C standard in C11:
>>>
>>> http://stackoverflow.com/questions/3228104/anonymous-union-within-struct-not-in-c99
>>>
>>> That's unfortunate, but I think we'd best give the unions a name (and let
>>> users change all code that uses them ...).
>>
>> I suppose we could do this. Actually, my_array.data.* isn't that bad.
>> (Would it be to verbose to do "my_array.data.as_doubles" while we're
>> on the topic of changing names?)
>
> +1 - people who care about shortcuts will use memory views anyway.
>
> I'll change it.
>
>
>>> BTW, is there any reason we have a "length" field at all? Shouldn't we be
>>> using Py_SIZE() ?
>>
>> I just kept the code as it was (which is why I added the extra compile
>> args), but wouldn't be opposed to this change either. Supporting
>> itemsize directly might be more useful.
>
> Hmm - how would you make "self->ob_descr->itemsize" available more directly?

I assume it's a function of Py_SIZE and sizeof(PyObject_HEAD), but
that's all the thinking I did about it.

- Robert