A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2004-December/050274.html below:

[Python-Dev] [Python 2.4] PyInt_FromLong returning NULL

[Python-Dev] [Python 2.4] PyInt_FromLong returning NULL [Python-Dev] [Python 2.4] PyInt_FromLong returning NULLTim Peters tim.peters at gmail.com
Tue Dec 7 19:17:19 CET 2004
[Tim]
>> ... but as a pragmatic matter PyInt_FromLong(1) can't fail --

[Jim]
> I know. I'm sure that's why we don't bother.  But, obviously,
> it can fail.

I disagree -- it's not obvious at all.  Looking at the code, it's far
more likely that Andreas misunderstood the cause of the failure than
that PyInt_FromLong(1) actually returned NULL.  If it did return NULL,
then it's got to be something as rare as bad code generation (for
reasons I explained earlier), or a non-standard compilation that
fiddled the NSMALLPOSINTS and/or NSMALLNEGINTS #defines to insane
values.

This is the entire expected path in PyInt_FromLong(1):

PyObject *
PyInt_FromLong(long ival)
{
	register PyIntObject *v;
#if NSMALLNEGINTS + NSMALLPOSINTS > 0
	if (-NSMALLNEGINTS <= ival && ival < NSMALLPOSINTS) {
		v = small_ints[ival + NSMALLNEGINTS];
		Py_INCREF(v);
#ifdef COUNT_ALLOCS
		if (ival >= 0)
			quick_int_allocs++;
		else
			quick_neg_int_allocs++;
#endif
		return (PyObject *) v;
	}
#endif

It's not possible for that to return NULL -- even if small_ints[] got
corrupted, so that v == NULL, the Py_INCREF(v) would have blown up
before the function could have returned.
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4