Compilation failes if a class member is named "INFINITY"
Hello, if I try to compile the following minimal example: cdef class Test: cdef readonly int INFINITY cython does not complain but gcc refuses with an error message: In file included from /usr/include/math.h:38:0, from /usr/include/python2.7/pyport.h:325, from /usr/include/python2.7/Python.h:58, from testinf.c:16: testinf.c:433:7: error: field '__builtin_inff' declared as a function int INFINITY; ^ testinf.c: In function '__pyx_pf_7testinf_4Test_8INFINITY___get__': testinf.c:569:50: error: expected identifier before '(' token __pyx_t_1 = __Pyx_PyInt_From_int(__pyx_v_self->INFINITY); if (unlikely(!__pyx_t_1)) {__pyx_filename = __pyx_f[0]; __pyx_lineno = 10; __pyx_clineno = __LINE__; goto __pyx_L1_error;} ^ Apparently the name "INFINITY" is handled wrongly; any other variable name seems to be fine. Regards, Michael
Hi, On Fri, Jan 30, 2015 at 1:49 AM, Michael <supermihi@posteo.de> wrote:
Hello,
if I try to compile the following minimal example:
cdef class Test:
cdef readonly int INFINITY
cython does not complain but gcc refuses with an error message: In file included from /usr/include/math.h:38:0, from /usr/include/python2.7/pyport.h:325, from /usr/include/python2.7/Python.h:58, from testinf.c:16: testinf.c:433:7: error: field '__builtin_inff' declared as a function int INFINITY; ^ testinf.c: In function '__pyx_pf_7testinf_4Test_8INFINITY___get__': testinf.c:569:50: error: expected identifier before '(' token __pyx_t_1 = __Pyx_PyInt_From_int(__pyx_v_self->INFINITY); if (unlikely(!__pyx_t_1)) {__pyx_filename = __pyx_f[0]; __pyx_lineno = 10; __pyx_clineno = __LINE__; goto __pyx_L1_error;} ^ Apparently the name "INFINITY" is handled wrongly; any other variable name seems to be fine.
Maybe you hit the INFINITY gcc macro? http://www.gnu.org/software/libc/manual/html_node/Infinity-and-NaN.html Cheers, Matthew
Am 31.01.2015 um 19:48 schrieb Matthew Brett:
Hi,
On Fri, Jan 30, 2015 at 1:49 AM, Michael <supermihi@posteo.de> wrote:
Hello,
if I try to compile the following minimal example:
cdef class Test:
cdef readonly int INFINITY
cython does not complain but gcc refuses with an error message: In file included from /usr/include/math.h:38:0, from /usr/include/python2.7/pyport.h:325, from /usr/include/python2.7/Python.h:58, from testinf.c:16: testinf.c:433:7: error: field '__builtin_inff' declared as a function int INFINITY; ^ testinf.c: In function '__pyx_pf_7testinf_4Test_8INFINITY___get__': testinf.c:569:50: error: expected identifier before '(' token __pyx_t_1 = __Pyx_PyInt_From_int(__pyx_v_self->INFINITY); if (unlikely(!__pyx_t_1)) {__pyx_filename = __pyx_f[0]; __pyx_lineno = 10; __pyx_clineno = __LINE__; goto __pyx_L1_error;} ^ Apparently the name "INFINITY" is handled wrongly; any other variable name seems to be fine.
Maybe you hit the INFINITY gcc macro?
http://www.gnu.org/software/libc/manual/html_node/Infinity-and-NaN.html
Yes, that's probably the explanation. So should Cython do anything about the problem, i.e. raise an exception if struct members are named like a macro? I don't know about the Cython internals, but I wonder why the name not altered in the c file: struct __pyx_obj_7testinf_Test { PyObject_HEAD int INFINITY; }; I would have expected something like "int __pyx_member_INFINITY"? Michael
Michael schrieb am 05.02.2015 um 09:52:
Am 31.01.2015 um 19:48 schrieb Matthew Brett:
On Fri, Jan 30, 2015 at 1:49 AM, Michael wrote:
if I try to compile the following minimal example:
cdef class Test:
cdef readonly int INFINITY
cython does not complain but gcc refuses with an error message: In file included from /usr/include/math.h:38:0, from /usr/include/python2.7/pyport.h:325, from /usr/include/python2.7/Python.h:58, from testinf.c:16: testinf.c:433:7: error: field '__builtin_inff' declared as a function int INFINITY; ^ testinf.c: In function '__pyx_pf_7testinf_4Test_8INFINITY___get__': testinf.c:569:50: error: expected identifier before '(' token __pyx_t_1 = __Pyx_PyInt_From_int(__pyx_v_self->INFINITY); if (unlikely(!__pyx_t_1)) {__pyx_filename = __pyx_f[0]; __pyx_lineno = 10; __pyx_clineno = __LINE__; goto __pyx_L1_error;} ^ Apparently the name "INFINITY" is handled wrongly; any other variable name seems to be fine.
Maybe you hit the INFINITY gcc macro?
http://www.gnu.org/software/libc/manual/html_node/Infinity-and-NaN.html
Yes, that's probably the explanation. So should Cython do anything about the problem, i.e. raise an exception if struct members are named like a macro?
Cython cannot know about everything that the C compiler (or its preprocessor) will eventually see in its flat namespace. So, no, Cython can't generally solve this problem for you.
I don't know about the Cython internals, but I wonder why the name not altered in the c file: struct __pyx_obj_7testinf_Test { PyObject_HEAD int INFINITY; }; I would have expected something like "int __pyx_member_INFINITY"?
Python extension types are just structs at the C level, and struct member names cannot be mangled. Plus, when types are external or public (or even just redeclared somewhere else by someone else), foreign code may depend on struct fields of extension types as well. Builtin types are an example. Stefan
Am 05.02.2015 um 10:44 schrieb Stefan Behnel:
Michael schrieb am 05.02.2015 um 09:52:
Am 31.01.2015 um 19:48 schrieb Matthew Brett:
On Fri, Jan 30, 2015 at 1:49 AM, Michael wrote:
if I try to compile the following minimal example:
cdef class Test:
cdef readonly int INFINITY
cython does not complain but gcc refuses with an error message: In file included from /usr/include/math.h:38:0, from /usr/include/python2.7/pyport.h:325, from /usr/include/python2.7/Python.h:58, from testinf.c:16: testinf.c:433:7: error: field '__builtin_inff' declared as a function int INFINITY; ^ testinf.c: In function '__pyx_pf_7testinf_4Test_8INFINITY___get__': testinf.c:569:50: error: expected identifier before '(' token __pyx_t_1 = __Pyx_PyInt_From_int(__pyx_v_self->INFINITY); if (unlikely(!__pyx_t_1)) {__pyx_filename = __pyx_f[0]; __pyx_lineno = 10; __pyx_clineno = __LINE__; goto __pyx_L1_error;} ^ Apparently the name "INFINITY" is handled wrongly; any other variable name seems to be fine.
Maybe you hit the INFINITY gcc macro?
http://www.gnu.org/software/libc/manual/html_node/Infinity-and-NaN.html
Yes, that's probably the explanation. So should Cython do anything about the problem, i.e. raise an exception if struct members are named like a macro?
Cython cannot know about everything that the C compiler (or its preprocessor) will eventually see in its flat namespace. So, no, Cython can't generally solve this problem for you.
I don't know about the Cython internals, but I wonder why the name not altered in the c file: struct __pyx_obj_7testinf_Test { PyObject_HEAD int INFINITY; }; I would have expected something like "int __pyx_member_INFINITY"?
Python extension types are just structs at the C level, and struct member names cannot be mangled. Plus, when types are external or public (or even just redeclared somewhere else by someone else), foreign code may depend on struct fields of extension types as well. Builtin types are an example.
Ok, that makes sense. I'll just choose a different name then. :-) Michael
_______________________________________________ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Stefan Behnel wrote:
Python extension types are just structs at the C level, and struct member names cannot be mangled.
Well, in principle it *could* mangle the names in structs that aren't declared "cdef extern". I didn't do that in Pyrex because it didn't seem necessary; I hadn't anticipated problems like collision with macros. It's probably too late to change it now, since it would break existing code that interoperates with foreign code. -- Greg
Am 05.02.2015 um 12:30 schrieb Greg Ewing:
Stefan Behnel wrote:
Python extension types are just structs at the C level, and struct member names cannot be mangled.
Well, in principle it *could* mangle the names in structs that aren't declared "cdef extern". I didn't do that in Pyrex because it didn't seem necessary; I hadn't anticipated problems like collision with macros.
It's probably too late to change it now, since it would break existing code that interoperates with foreign code.
To me, that sounds like a too complicated solution for a marginal problem. It's a bit odd that you can't use special names like INFINITY for cdef class members, but on the other hand, I think that's a reasonable restriction since you are generating C code, and in C you can't name a struct member INFINITY either (at least with gcc).
participants (4)
-
Greg Ewing -
Matthew Brett -
Michael -
Stefan Behnel