> On Sat, May 16, 2009 at 1:44 PM, Dag Sverre Seljebotn
> <[email protected]> wrote:
>>> I've already implemented the @cython.callspec("something") and 'cdef
>>> callspec("something") void f()'
>>>
>>> The first one is enough to solve my issues in mpi4py, so I would
>>> really like to get at least that part in. That change should be really
>>> safe, no parser modifications involved.
>>>
>>> About the second one, I'm still not sure about that syntax. Moreover,
>>> it modifies the parser so this could potentially break things.
>>>
>>> What do you think about pushing the decorator form for 0.11.2, and
>>> defer the other for a future release?
>>
>> +1. Just push it.
>>
>
> OK.  I'm going to add this:
>
> -calling_convention_words = ("__stdcall", "__cdecl")
> +calling_convention_words = ("__stdcall", "__cdecl", "__fastcall")
>
>
> Buth then, I'm in doubt about what to do with this bit:
>
>      def same_calling_convention_as(self, other):
>         sc1 = self.calling_convention == '__stdcall'
>         sc2 = other.calling_convention == '__stdcall'
>         return sc1 == sc2
>
> This code did not take into account "__fastcall". Moreover, it assumes
> that "__cdecl" is compatible with a empty calling convention. But IMHO
> that is dangerous, as the actual calling convention for functions with
> empty callspec can be tweaked by passing flags to the C compiler.
>
> I'm thinking about doing things like this:
>
>      def same_calling_convention_as(self, other):
>         callspec_words = ("__stdcall", "__cdecl", "__fastcall")
>         cs1 =
>         cs2 = other.calling_convention
>         if (cs1 in callspec_words or
>             cs2 in callspec_words):
>             return cs1 == cs2
>         else:
>             return True

Why is this function only considering those, and not user-defined
callspecs as well?

It would seem to me that simply

self.calling_convention == other.calling_convention

would seem natural here, if one cannot trust "no convention" to be the
same as any others.

Dag Sverre

_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev

Reply via email to