[Pyrex] Pyrex ctypedef bug?

[John J Lee]

I'm using Pyrex 0.9.2.1 on Python 2.3.

I have the following in my wrapper of spidermonkey (Mozilla's JavaScript
implementation):

cdef extern from "jsapi.h":
...snip...
    ctypedef int jsval
    ctypedef int jsid
    ctypedef int jsword


These are typedef'd to long in (headers included by) jsapi.h.

Robert Walsh compiled this on an AMD64 box (not sure what Python version,
but he's using Pyrex 0.9.2.1) and discovered that he got an access
violation.  The access violation goes away when he edits the above to
read:

cdef extern from "jsapi.h":
...snip...
    ctypedef long jsval
    ctypedef long jsid
    ctypedef long jsword


The reason is that, though I define a variable rval like so:

    def eval_script(self, script):
        cdef jsval rval
...

Pyrex generates code with C type int (or long, depending on the Pyrex
ctypedef), not jsval:

static PyObject *__pyx_f_12spidermonkey_7Context_eval_script(PyObject
*__pyx_v_self, PyObject *__pyx_args, PyObject *__pyx_kwds) {
  PyObject *__pyx_v_script = 0;
  int __pyx_v_rval;
...


However, the Pyrex docs insist that:

| If the header file uses typedef names such as size_t to refer to
| platform-dependent flavours of numeric types, you will need a
| corresponding ctypedef statement, but you don't need to match the type
| exactly, just use something of the right general kind (int, float, etc).
| For example,
|
| ctypedef int size_t
|
| will work okay whatever the actual size of a size_t is (provided the
| header file defines it correctly).

So the generated C code should be defining __pyx_v_rval as a jsval, not an
int, right?


John