[Python-Dev] Buildbot report (almost July)

Steve Dower steve.dower at python.org
Thu Jun 29 15:22:00 EDT 2017


On 29Jun2017 1157, Terry Reedy wrote:
> On 6/29/2017 1:54 PM, Steve Dower wrote:
>> Some warnings are also complicated because of the nature of CPython. 
>> For example, the socket module exposes deprecated CRT functions (on 
>> Windows) directly because the API of the socket module promises to 
>> provide the function directly. Changing to the safer function would 
>> break the API guarantee (except sometimes it won't... hence 
>> "complicated").
> 
> Thanks for the explanation.  Does 'deprecated' mean future removal in 
> ms-speak?  Perhaps after the compile, build.bat should print something like
> [Ignore any socket deprecation warnings]

Probably not future removal, considering the vast quantities of legacy 
code that we don't want to break, but renaming is possible (generally 
for standards compliance, such as the timezone->_timezone rename) and 
new platforms (e.g. ARM) are not guaranteed to have the APIs when there 
is essentially no existing code to worry about.

In many (most?) cases, deprecations in MS libraries indicate that there 
are known security issues either inherently in the function itself or 
with many/most uses of it, and there is a better option (e.g. strcpy is 
deprecated in favour of strcpy_s, which requires/infers the length of 
the destination buffer and ensures you never overflow).

I'm still in favour of local suppression over ignoring warnings - we 
just need to promote the macro at 
https://github.com/python/cpython/blob/master/Modules/socketmodule.c#L510 
to somewhere global to make it consistent (and maybe extend it to handle 
other compilers where it matters).

But this is why I'm not against the general idea, but it requires that 
the devguide entry be well written. Let's clean up all the warnings, but 
in the right way, not the way people use when faced with arbitrary rules.

Cheers,
Steve


More information about the Python-Dev mailing list