On Oct 3, 2008, at 7:15 AM, Lisandro Dalcin wrote: > On Fri, Oct 3, 2008 at 5:32 AM, Robert Bradshaw > <[EMAIL PROTECTED]> wrote: >> On Oct 1, 2008, at 6:42 PM, Lisandro Dalcin wrote: >> >>> Robert, in this changeset >>> >>> changeset: 1184:515f94dc16f2 >>> user: Robert Bradshaw <[EMAIL PROTECTED]> >>> date: Mon Sep 29 19:08:45 2008 -0700 >>> summary: Refactoring of type parsing >>> >>> you cannot parse C function typedef like this: >>> >>> cdef extern from *: >>> void (somefunc)(int) >>> >>> Please note that this declaration is not of the form "void >>> (*somefuncptr)(int)", and AFAIK the former is valid C code. >> >> Does it have the same meaning, or is there something more subtle >> going on? > > Robert, AFAIK they do not have the same meaning. the void > (func1)(args) is function typedef and void (*func2)(args) is a funtion > POINTER typedef. In short, they are really different types. MPI has > many of those (non-pointer) typedef for some callback functions.
I understand that they are different types, I thought the one could be used wherever the other is needed though. > I really believe that this is a regression. It could potentially make > invalid some codes. In fact, this change already broke my codes. OK, I'll look into this some more then. Being able to use "cimport *" to import types is why I had to make these changes. >> We don't accept all valid C code, for example >> >> int foo(void) >> >> is allowed in C but not in Cython. > > Long ago I discussed that case with Sfefan, and we agreed that there > was not point on supporting 'int foo(void)', as that C declaration was > in fact related to support ancient C and the different meaning of 'int > foo()', hopefully fixed in C++. > > But in the fase of function vs. function pointer typedef's, the issues > are different. They really are different types. > > >>> I was looking at the changes you pushed, but I was unable to >>> discover >>> what's going on. So I really need your help here. >> >> I needed to remove the dependancy the parser had on knowing all type >> names, so in some places it needs to look ahead to determine if it's >> looking at a type or an expression. If this is the only bug >> introduced, than I'm willing to accept that, but are there other >> statements that are now illegal? >> >> - Robert >> >> _______________________________________________ >> Cython-dev mailing list >> [email protected] >> http://codespeak.net/mailman/listinfo/cython-dev >> > > > > -- > Lisandro Dalcín > --------------- > Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) > Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) > Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) > PTLC - Güemes 3450, (3000) Santa Fe, Argentina > Tel/Fax: +54-(0)342-451.1594 > _______________________________________________ > Cython-dev mailing list > [email protected] > http://codespeak.net/mailman/listinfo/cython-dev _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
