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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
