[issue36161] Use thread-safe functions instead of unsafe ones (crypt, ttyname)

Benjamin Peterson added the comment: New changeset 594e2edfb5e0d24e03469d035d8f39ff29a64d99 by Benjamin Peterson (Antonio Gutierrez) in branch 'master': closes bpo-36161: Use thread-safe ttyname_r instead of ttyname. (GH-14868)

[issue36161] Use thread-safe functions instead of unsafe ones (crypt, ttyname)

Change by Antonio Gutierrez : -- pull_requests: +16187 pull_request: https://github.com/python/cpython/pull/16599 ___ Python tracker ___

[issue36161] Use thread-safe functions instead of unsafe ones (crypt, ttyname)

Christian Heimes added the comment: Does it make sense to modify crypt at all? PEP 594 is going to deprecate and remove crypt soon. -- nosy: +christian.heimes ___ Python tracker

[issue36161] Use thread-safe functions instead of unsafe ones (crypt, ttyname)

Change by Antonio Gutierrez : -- keywords: +patch pull_requests: +14655 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/14868 ___ Python tracker

[issue36161] Use thread-safe functions instead of unsafe ones (crypt, ttyname)

Thomas Wouters added the comment: Ah, looks like I missed crypt_r getting added in 3.7. Sorry about that. Yes, the error handling would be a behaviour change, a keyword argument may be a good solution. As it is, crypt() returns None, throwing away the *reason* for the failure (which is

[issue36161] Use thread-safe functions instead of unsafe ones (crypt, ttyname)

Martin Panter added the comment: In Issue 28503, “crypt_r” was added to Python 3.7 and 3.8+, and it looks like it is still there. Regarding error handling for “crypt”, it is not documented, but the Python function returns None on error. You would have to consider backwards compatibility to

[issue36161] Use thread-safe functions instead of unsafe ones (crypt, ttyname)

New submission from Thomas Wouters : (good first issue, I think.) CPython currently uses a few functions that are thread-unsafe where thread-safe version exist, at least in glibc (crypt() and ttyname(), at least). This isn't an issue when looking at CPython in isolation because these calls