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/2002-June/025242.html below:

[Python-Dev] Null checking

[Python-Dev] Null checkingGuido van Rossum guido@python.org
Mon, 10 Jun 2002 09:32:08 -0400
> A couple of quick questions for the authors of the Python source: I
> notice that most, if not all, of the Python 'C' API includes null
> checks for the PyObject* arguments, meaning that you can't crash
> Python by passing the result of a previous operation, even if it
> returns an error.
> 
> First question: can that be counted on? Hmm, I guess I've answered
> my own question -- PyNumber_InPlaceAdd has no checks.

Unless documented explicitly you cannot count on it!

> I note that the null_error() check in abstract.c is non-destructive:
> it preserves any existing error, whereas other checks (e.g. in
> typeobject.c) do not.

Different goals.  (I'm not sure which checks in typeobject.c you're
referring to.)

> Second question: I guess I really want to know what the intention
> behind these checks is. Is it something like "prevent extension
> writers from crashing Python in some large percentage of cases", or
> is there a deeper plan that I'm missing?

Jim Fulton contributed the code that uses null_error().  I think he
was making it possible to pass the result from one call to the next
without doing the error checking on the first call.  Personally, I
find that inexcusable laziness and I don't intend to encourage it or
propagate this style to other APIs.

--Guido van Rossum (home page: http://www.python.org/~guido/)




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