new arrayarray.h header file not C99 compatible
Hi, 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... That's unfortunate, but I think we'd best give the unions a name (and let users change all code that uses them ...). BTW, is there any reason we have a "length" field at all? Shouldn't we be using Py_SIZE() ? Stefan
Stefan Behnel, 20.08.2012 15:39:
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...
That's unfortunate, but I think we'd best give the unions a name (and let users change all code that uses them ...).
Hmm, although - our test runner has this: """ def update_pyarray_extension(ext): # See http://gcc.gnu.org/onlinedocs/gcc/Unnamed-Fields.html#Unnamed-Fields ext.extra_compile_args.append('-fms-extensions') """ Is that really the way it should be handled?
BTW, is there any reason we have a "length" field at all? Shouldn't we be using Py_SIZE() ?
Stefan
On Mon, Aug 20, 2012 at 6:39 AM, Stefan Behnel <stefan_ml@behnel.de> wrote:
Hi,
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...
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?)
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. - Robert
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...
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
On Mon, Aug 20, 2012 at 9:10 AM, Stefan Behnel <stefan_ml@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...
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
participants (2)
-
Robert Bradshaw -
Stefan Behnel