summaryrefslogtreecommitdiffstats
path: root/Include/internal/pycore_bytesobject.h
Commit message (Collapse)AuthorAgeFilesLines
* [3.13] gh-133767: Fix use-after-free in the unicode-escape decoder with an ↵Serhiy Storchaka2025-05-201-0/+4
| | | | | | | | | | | | | | | | | error handler (GH-129648) (GH-133944) If the error handler is used, a new bytes object is created to set as the object attribute of UnicodeDecodeError, and that bytes object then replaces the original data. A pointer to the decoded data will became invalid after destroying that temporary bytes object. So we need other way to return the first invalid escape from _PyUnicode_DecodeUnicodeEscapeInternal(). _PyBytes_DecodeEscape() does not have such issue, because it does not use the error handlers registry, but it should be changed for compatibility with _PyUnicode_DecodeUnicodeEscapeInternal(). (cherry picked from commit 9f69a58623bd01349a18ba0c7a9cb1dad6a51e8e) Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
* [3.13] gh-121489: Export private _PyBytes_Join() again (GH-122267) (#122287)Miss Islington (bot)2024-07-251-4/+0
| | | | | | gh-121489: Export private _PyBytes_Join() again (GH-122267) (cherry picked from commit aef95eb107fef9355c66461612aedd31265f8c21) Co-authored-by: Marc Mueller <30130371+cdce8p@users.noreply.github.com>
* gh-107211: No longer export internal functions (5) (#108423)Victor Stinner2023-08-241-18/+23
| | | | | | No longer export _PyCompile_AstOptimize() internal C API function. Change comment style to "// comment" and add comment explaining why other functions have to be exported.
* gh-106320: Remove _PyBytes_Join() C API (#107144)Victor Stinner2023-07-231-0/+19
| | | | | | | | | | | Move private _PyBytes functions to the internal C API (pycore_bytesobject.h): * _PyBytes_DecodeEscape() * _PyBytes_FormatEx() * _PyBytes_FromHex() * _PyBytes_Join() No longer export these functions.
* gh-106320: Remove _PyBytesWriter C API (#106399)Victor Stinner2023-07-041-0/+81
| | | | Remove the _PyBytesWriter C API: move it to the internal C API (pycore_bytesobject.h).
* gh-94673: Ensure Builtin Static Types are Readied Properly (gh-103940)Eric Snow2023-04-271-5/+0
| | | There were cases where we do unnecessary work for builtin static types. This also simplifies some work necessary for a per-interpreter GIL.
* bpo-47070: Add _PyBytes_Repeat() (GH-31999)Pieter Eendebak2022-03-281-0/+13
| | | Use it where appropriate: the repeat functions of `array.array`, `bytes`, `bytearray`, and `str`.
* Fix typo in pycore_bytesobject.h (GH-31914)jonasdlindner2022-03-211-1/+1
|
* bpo-46848: Move _PyBytes_Find() to internal C API (GH-31642)Victor Stinner2022-03-021-0/+19
| | | | | | Move _PyBytes_Find() and _PyBytes_ReverseFind() functions to the internal C API. bytesobject.c now includes pycore_bytesobject.h.
* bpo-45953: Statically allocate and initialize global bytes objects. (gh-30096)Eric Snow2022-01-111-10/+0
| | | | | The empty bytes object (b'') and the 256 one-character bytes objects were allocated at runtime init. Now we statically allocate and initialize them. https://bugs.python.org/issue45953
* bpo-46008: Make runtime-global object/type lifecycle functions and state ↵Eric Snow2021-12-091-0/+30
consistent. (gh-29998) This change is strictly renames and moving code around. It helps in the following ways: * ensures type-related init functions focus strictly on one of the three aspects (state, objects, types) * passes in PyInterpreterState * to all those functions, simplifying work on moving types/objects/state to the interpreter * consistent naming conventions help make what's going on more clear * keeping API related to a type in the corresponding header file makes it more obvious where to look for it https://bugs.python.org/issue46008