Description

serhiy-storchaka

opened on Apr 16, 2016

Issue body actions

BPO	26776
Nosy	@vstinner, @serhiy-storchaka
Files	check_error_occurred.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2016-04-16.08:02:38.488>
labels = ['interpreter-core']
title = 'Determining the failure of C API call is ambiguous'
updated_at = <Date 2016-04-16.09:27:24.259>
user = 'https://github.com/serhiy-storchaka'

bugs.python.org fields:

activity = <Date 2016-04-16.09:27:24.259>
actor = 'vstinner'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2016-04-16.08:02:38.488>
creator = 'serhiy.storchaka'
dependencies = []
files = ['42478']
hgrepos = []
issue_num = 26776
keywords = ['patch']
message_count = 2.0
messages = ['263540', '263544']
nosy_count = 2.0
nosy_names = ['vstinner', 'serhiy.storchaka']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = None
url = 'https://bugs.python.org/issue26776'
versions = []

Activity

1. serhiy-storchaka commented on Apr 16, 2016

   

   serhiy-storchaka

   on Apr 16, 2016

   MemberAuthor

   More actions

   C API functions returns a special value unambiguously signaling about a raised exception (NULL or -1). But in some cases this is ambiguous, because the special value is a legitimate value (e.g. -1 for PyLong_AsLong() or NULL for PyDict_GetItem()). Needed to use PyErr_Occurred() to distinguish between successful and failed call.

   The problem is that if PyLong_AsLong() is called when the exception is set, successful call returned -1 is interpreted as failed. Since it is happen in very rare case, this bug is usually unnoticed.

   Attached experimental patch makes some functions like PyLong_AsLong() always failing if called with an exception set. Some tests are failed with it applied: test_compile test_datetime test_io test_os test_symtable test_syntax test_xml_etree_c.
2. serhiy-storchaka

   added

   interpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)

   on Apr 16, 2016
3. vstinner commented on Apr 16, 2016

   

   vstinner

   on Apr 16, 2016

   Member

   More actions

   Ah yes. Some months (years?) ago, i started to add assertions to fail if
   some functions are called with an exception set.

   Checking if an exception is set at runtime adds a low overhead. Maybe it's
   better to fail with a fatal error (like an assertion error) in debug mode
   (and do nothing in release mode).

   But I'm not sure that developers of C extensions are all able to get a
   Python compiled in debug mode :-/ That's also why I added a check a
   runtime: raise a SystemError if a function with an exception set. I also
   added PYTHONMALLOC=debug to make some debug checks easily available on
   release builds.

   The bug also reminds me my PEP-490 to chain exceptions. It would be
   yet another option...

   So well, I don't know what is the best option.
4. ezio-melotti

   transferred this issue fromon Apr 10, 2022
5. vstinner

   added

   topic-C-API

   on Jul 19, 2026

Issue actions