Repository navigation
gh-161518: Reject a non-bytes encoder result unless it is the ASCII fast path - #161531
Open
harjothkhara wants to merge 1 commit into
Open
harjothkhara wants to merge 1 commit into
harjothkhara wants to merge 1 commit into
Conversation
…SCII fast path TextIOWrapper.write() accepted any encoder result that was the same object as its input. That is only safe for ASCII text, so a custom encoder returning a non-ASCII str wrote corrupt data. Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
TextIOWrapper.write()skips its "encoder should return a bytes object" check when the encoder returns the very samestrit was given. That exemption is only valid for the internal ASCII fast path. A custom encoder that returns its non-ASCII input therefore had thestr's internal storage written as bytes: a release build silently writes the wrong bytes, and a debug build aborts on an assertion in_textiowrapper_writeflush.The check now accepts the same-object result only for ASCII text, so this case raises
TypeErrorlike any other encoder that does not return bytes. An encoder that returns the same ASCIIstris still accepted, as before.Added
test_encoder_returns_str. It fails on the unfixed code (assertion on a debug build, no error on a release build) and passes with the change.test_ioandtest_codecspass on a debug build.I used AI assistance for this and have reviewed the change.