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

Antoine Pitrou solipsis at pitrou.net
Wed Jul 24 10:17:59 CEST 2013


Le Wed, 24 Jul 2013 09:01:30 +0200,
Ronald Oussoren <ronaldoussoren at mac.com> a écrit :
> 
> On 24 Jul, 2013, at 8:43, Gregory P. Smith <greg at krypto.org> wrote:
> 
> > 
> > On Tue, Jul 23, 2013 at 8:46 AM, Ronald Oussoren
> > <ronaldoussoren at mac.com> wrote:
> > 
> > On 23 Jul, 2013, at 17:36, Christian Heimes <christian at python.org>
> > 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.




More information about the Python-Dev mailing list