Mailman 3 Re: [Python-Dev] cpython (3.3): return NULL here - Python-Dev

newer
Python 3 as a Default in Linux...

Re: [Python-Dev] cpython (3.3): return NULL here

older
Re: [Python-Dev] cpython: Add...

Christian Heimes

23 Jul 2013 23 Jul '13

10 a.m.

Am 23.07.2013 07:08, schrieb benjamin.peterson:

...

http://hg.python.org/cpython/rev/042ff9325c5e changeset: 84804:042ff9325c5e branch: 3.3 parent: 84789:bb63f813a00f user: Benjamin Peterson date: Mon Jul 22 22:08:09 2013 -0700 summary: return NULL here

files: Python/dynload_shlib.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/Python/dynload_shlib.c b/Python/dynload_shlib.c --- a/Python/dynload_shlib.c +++ b/Python/dynload_shlib.c @@ -91,7 +91,8 @@ int i; struct stat statb; if (fstat(fileno(fp), &statb) == -1) { - return PyErr_SetFromErrno(PyExc_IOError); + PyErr_SetFromErrno(PyExc_IOError); + return NULL; }

PyErr_SetFromErrno() already and always returns NULL. Or do you prefer to return NULL explicitly? Christian

Show replies by date

Benjamin Peterson

23 Jul 23 Jul

3:10 p.m.

New subject: [Python-checkins] cpython (3.3): return NULL here

2013/7/23 Christian Heimes :

...

Am 23.07.2013 07:08, schrieb benjamin.peterson:

...
http://hg.python.org/cpython/rev/042ff9325c5e changeset: 84804:042ff9325c5e branch: 3.3 parent: 84789:bb63f813a00f user: Benjamin Peterson date: Mon Jul 22 22:08:09 2013 -0700 summary: return NULL here

files: Python/dynload_shlib.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/Python/dynload_shlib.c b/Python/dynload_shlib.c --- a/Python/dynload_shlib.c +++ b/Python/dynload_shlib.c @@ -91,7 +91,8 @@ int i; struct stat statb; if (fstat(fileno(fp), &statb) == -1) { - return PyErr_SetFromErrno(PyExc_IOError); + PyErr_SetFromErrno(PyExc_IOError); + return NULL; }

PyErr_SetFromErrno() already and always returns NULL. Or do you prefer to return NULL explicitly?

It might always return NULL, but the compiler sees (PyObject *)NULL when this function returns dl_funcptr. -- Regards, Benjamin

Christian Heimes

3:36 p.m.

New subject: cpython (3.3): return NULL here

Am 23.07.2013 17:10, schrieb Benjamin Peterson:

...

...
PyErr_SetFromErrno() already and always returns NULL. Or do you prefer to return NULL explicitly?

It might always return NULL, but the compiler sees (PyObject *)NULL when this function returns dl_funcptr.

Oh, you are right. I must have missed the compiler warning. How about we turn type return and type assignment warnings into fatal errors? Christian

Ronald Oussoren

3:46 p.m.

New subject: cpython (3.3): return NULL here

On 23 Jul, 2013, at 17:36, Christian Heimes wrote:

...

Am 23.07.2013 17:10, schrieb Benjamin Peterson:

...
...
PyErr_SetFromErrno() already and always returns NULL. Or do you prefer to return NULL explicitly?

It might always return NULL, but the compiler sees (PyObject *)NULL when this function returns dl_funcptr.

Oh, you are right. I must have missed the compiler warning. How about we turn type return and type assignment warnings into fatal errors?

That's probably possible with a '-Werror=....' argument. But please consider issue 18211 before unconditionally adding such a flag, as that issue mentions new compiler flags also get used when compiling 3th-party extensions. I guess there needs to be (yet) another CFLAGS_xxx variable in the Makefile that gets added to $(CFLAGS) during the build of Python itself, but is ignored by distutils and sysconfig. Ronald

...

Christian

_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com

Gregory P. Smith

24 Jul 24 Jul

6:43 a.m.

New subject: [Python-checkins] cpython (3.3): return NULL here

On Tue, Jul 23, 2013 at 8:46 AM, Ronald Oussoren wrote:

...

On 23 Jul, 2013, at 17:36, Christian Heimes wrote:

...
Am 23.07.2013 17:10, schrieb Benjamin Peterson:

...
...
PyErr_SetFromErrno() already and always returns NULL. Or do you prefer to return NULL explicitly?

It might always return NULL, but the compiler sees (PyObject *)NULL when this function returns dl_funcptr.

Oh, you are right. I must have missed the compiler warning. How about we turn type return and type assignment warnings into fatal errors?

That's probably possible with a '-Werror=....' argument. But please consider issue 18211 before unconditionally adding such a flag, as that issue mentions new compiler flags also get used when compiling 3th-party extensions.

I guess there needs to be (yet) another CFLAGS_xxx variable in the Makefile that gets added to $(CFLAGS) during the build of Python itself, but is ignored by distutils and sysconfig.

It seems fair to turn those on in 3.4 and require that third party extensions clean up their code when porting from 3.3 to 3.4.

...

Ronald

...
Christian

_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

http://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com

_______________________________________________ Python-checkins mailing list Python-checkins@python.org http://mail.python.org/mailman/listinfo/python-checkins

Ronald Oussoren

7:01 a.m.

New subject: [Python-checkins] cpython (3.3): return NULL here

On 24 Jul, 2013, at 8:43, Gregory P. Smith wrote:

...

On Tue, Jul 23, 2013 at 8:46 AM, Ronald Oussoren wrote:

On 23 Jul, 2013, at 17:36, Christian Heimes wrote:

...
Am 23.07.2013 17:10, schrieb Benjamin Peterson:

...
...
PyErr_SetFromErrno() already and always returns NULL. Or do you prefer to return NULL explicitly?

It might always return NULL, but the compiler sees (PyObject *)NULL when this function returns dl_funcptr.

Oh, you are right. I must have missed the compiler warning. How about we turn type return and type assignment warnings into fatal errors?

That's probably possible with a '-Werror=....' argument. But please consider issue 18211 before unconditionally adding such a flag, as that issue mentions new compiler flags also get used when compiling 3th-party extensions.

I guess there needs to be (yet) another CFLAGS_xxx variable in the Makefile that gets added to $(CFLAGS) during the build of Python itself, but is ignored by distutils and sysconfig.

It seems fair to turn those on in 3.4 and require that third party extensions clean up their code when porting from 3.3 to 3.4.

In this case its "just" code cleanup, the issue I filed (see above) is for another -Werror flag that causes compile errors with some valid C99 code that isn't valid C89. That's good for CPython itself because its source code is explicitly C89, but is not good when building 3th-party extensions. A proper fix requires tweaking the configure script, Makefile and distutils and that's not really a fun prospect ;-) Ronald

...

Ronald

...
Christian

_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com

_______________________________________________ Python-checkins mailing list Python-checkins@python.org http://mail.python.org/mailman/listinfo/python-checkins

_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com

Antoine Pitrou

8:17 a.m.

New subject: [Python-checkins] cpython (3.3): return NULL here

Le Wed, 24 Jul 2013 09:01:30 +0200, Ronald Oussoren a écrit :

...

On 24 Jul, 2013, at 8:43, Gregory P. Smith wrote:

...
On Tue, Jul 23, 2013 at 8:46 AM, Ronald Oussoren wrote:

On 23 Jul, 2013, at 17:36, Christian Heimes wrote:

...
Am 23.07.2013 17:10, schrieb Benjamin Peterson:

...
...
PyErr_SetFromErrno() already and always returns NULL. Or do you prefer to return NULL explicitly?

It might always return NULL, but the compiler sees (PyObject *)NULL when this function returns dl_funcptr.

Oh, you are right. I must have missed the compiler warning. How about we turn type return and type assignment warnings into fatal errors?

That's probably possible with a '-Werror=....' argument. But please consider issue 18211 before unconditionally adding such a flag, as that issue mentions new compiler flags also get used when compiling 3th-party extensions.

I guess there needs to be (yet) another CFLAGS_xxx variable in the Makefile that gets added to $(CFLAGS) during the build of Python itself, but is ignored by distutils and sysconfig.

It seems fair to turn those on in 3.4 and require that third party extensions clean up their code when porting from 3.3 to 3.4.

In this case its "just" code cleanup, the issue I filed (see above) is for another -Werror flag that causes compile errors with some valid C99 code that isn't valid C89. That's good for CPython itself because its source code is explicitly C89, but is not good when building 3th-party extensions.

Agreed. We shouldn't impose specific error flags on 3rd-party extension writers. Regards Antoine.

3928

Age (days ago)

3929

Last active (days ago)

List overview

Download

6 comments

5 participants

participants (5)

Antoine Pitrou
Benjamin Peterson
Christian Heimes
Gregory P. Smith
Ronald Oussoren

Re: [Python-Dev] cpython (3.3): return NULL here

Christian Heimes

Benjamin Peterson

Christian Heimes

Ronald Oussoren

Gregory P. Smith

Ronald Oussoren

Antoine Pitrou

tags

participants (5)