[Cython] C int division by zero
Robert Bradshaw
robertwb at math.washington.edu
Tue Apr 14 21:33:51 CEST 2009
On Apr 14, 2009, at 12:18 PM, Dag Sverre Seljebotn wrote:
> Robert Bradshaw wrote:
>> On Apr 14, 2009, at 9:17 AM, Dag Sverre Seljebotn wrote:
>>
>>> I was just thinking about this:
>>>
>>> cdef int a = 10, b = 0
>>> print a // b
>>>
>>> which currently gives a C exception terminating the Python
>>> interpreter.
>>>
>>> On one hand: We have already changed division to Python behaviour
>>> (with
>>> a speed penalty); so using the same arguments (which I won't
>>> reiterate)
>>> it would make sense to raise a Python exception instead here.
>>
>> Since we changed it, we should chang it all the way. It will be
>> somewhat uglier as this means when writing a / (c-c) one needs to
>> store the denominator in a temp and check it rather than simply
>> letting the expression through to C (I already did this for
>> warnings).
>
> We're already in beta, but still: Can we get a warning cycle for
> this as
> well into 0.11.1 so that people only have to deal with C int semantic
> changes once? I can probably make it tomorrow but I'll have a higher
> learning curve as you did the previous change.
Yes, I'll do this. I think segfault -> ZeroDivisionError exception
will be an easy migration path for most people :).
>>> One solution would be to work on accepting exceptions under nogil,
>>> another one would be to require use of cdivision directive/cdiv
>>> to do
>>> division in nogil sections.
>>
>> I don't think exceptions are safe without the gil. With cdivision on
>> it won't raise anything.
>
> This is an exceptional case; I think it is OK to acquire the GIL
> temporarily to construct the exception if the exception hits, as
> long as
> non-exception paths doesn't require waiting for a GIL lock?
>
> See also the other thread on this.
Hmm... I don't have a definite opinion on this yet, but that might be
reasonable. Propagating an exception requires the gil too...it
dilutes the pureness of "no gil."
- Robert
More information about the Cython-dev
mailing list