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

[Stefan Behnel]

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?

Stefan