[issue33231] Potential memory leak in normalizestring()

[INADA Naoki]

Change by INADA Naoki :


--
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33231] Potential memory leak in normalizestring()

[INADA Naoki]

Change by INADA Naoki :


--
resolution:  -> fixed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33231] Potential memory leak in normalizestring()

[miss-islington]

miss-islington  added the comment:


New changeset 2350a4765265158072bf7ad9f04402406d3d1ada by Miss Islington (bot) 
in branch '3.6':
bpo-33231: Fix potential leak in normalizestring() (GH-6386)
https://github.com/python/cpython/commit/2350a4765265158072bf7ad9f04402406d3d1ada


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33231] Potential memory leak in normalizestring()

[miss-islington]

miss-islington  added the comment:


New changeset 64421d9237e33725e3c2916cdf2b6d6da1751c2a by Miss Islington (bot) 
in branch '3.7':
bpo-33231: Fix potential leak in normalizestring() (GH-6386)
https://github.com/python/cpython/commit/64421d9237e33725e3c2916cdf2b6d6da1751c2a


--
nosy: +miss-islington

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33231] Potential memory leak in normalizestring()

[miss-islington]

Change by miss-islington :


--
pull_requests: +6102

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33231] Potential memory leak in normalizestring()

[INADA Naoki]

INADA Naoki  added the comment:


New changeset 0c1c4563a65ac451021d927058e4f25013934eb2 by INADA Naoki in branch 
'master':
bpo-33231: Fix potential leak in normalizestring() (GH-6386)
https://github.com/python/cpython/commit/0c1c4563a65ac451021d927058e4f25013934eb2


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33231] Potential memory leak in normalizestring()

[miss-islington]

Change by miss-islington :


--
pull_requests: +6101

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33231] Potential memory leak in normalizestring()

[INADA Naoki]

INADA Naoki  added the comment:

> Only reason I can see to avoid this would be if the codec names could contain 
> arbitrary Unicode encoded as UTF-8 (and therefore strlen wouldn't tell you 
> the final length in Unicode ordinals), but I'm pretty sure that's not the 
> case (if it is, we're not normalizing properly, since we only lower case 
> ASCII). If Unicode codec names need to be handled, there are other options, 
> though the easy savings go away.

Maybe, we can add "encoding name must be ascii" restriction in future version 
(3.8+).
But for now, I want to avoid any potential backward incompatibility.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33231] Potential memory leak in normalizestring()

[Josh Rosenberg]

New submission from Josh Rosenberg :

Patch is good, but while we're at it, is there any reason why this 
multi-allocation design was even used? It PyMem_Mallocs a buffer, makes a 
C-style string in it, then uses PyUnicode_FromString to convert C-style string 
to Python str.

Seems like the correct approach would be to just use PyUnicode_New to 
preallocate the final string buffer up front, then pull out the internal buffer 
with PyUnicode_1BYTE_DATA and populate that directly, saving a pointless 
allocation/deallocation, which also means the failure case means no cleanup 
needed at all, while barely changing the code (aside from removing the need to 
explicitly NUL terminate).

Only reason I can see to avoid this would be if the codec names could contain 
arbitrary Unicode encoded as UTF-8 (and therefore strlen wouldn't tell you the 
final length in Unicode ordinals), but I'm pretty sure that's not the case (if 
it is, we're not normalizing properly, since we only lower case ASCII). If 
Unicode codec names need to be handled, there are other options, though the 
easy savings go away.

--
nosy: +josh.r

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33231] Potential memory leak in normalizestring()

[INADA Naoki]

Change by INADA Naoki :


--
keywords: +patch
pull_requests: +6095
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33231] Potential memory leak in normalizestring()

[INADA Naoki]

Change by INADA Naoki :


--
components: Interpreter Core
nosy: inada.naoki
priority: normal
severity: normal
status: open
title: Potential memory leak in normalizestring()
type: resource usage
versions: Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com