Repository navigation
Fix encoding 866 crash: fallback to UTF-8 when console encoding unavailable - #365
Open
dronov-dmitry wants to merge 2 commits into
Open
dronov-dmitry wants to merge 2 commits into
dronov-dmitry wants to merge 2 commits into
Conversation
…coding unavailable SharedIO.InitializeInput/Output/ErrorOutput accessed Console.InputEncoding and Console.Out/Console.Error without error handling. On systems where cp866 (or other console encodings) are not registered (e.g. Dynamo/Revit hosting environment, .NET Core), this threw ArgumentException: 'No data is available for encoding 866' Added TryGetConsoleEncoding() helper that wraps encoding access in try-catch and falls back to Encoding.UTF8 / TextWriter.Null when the console encoding is unavailable.
Author
|
@dotnet-policy-service agree |
The previous change guarded Console.InputEncoding/Console.Out.Encoding but still failed in the situations it was meant to survive: 1. Console.In is built from Console.InputEncoding (see ConsolePal.GetOrCreateReader), so it threw again right after the guarded read and the engine still failed to start. 2. The output/error ternary evaluated Console.Out / Console.Error a second time outside the try, so the UTF-8 fallback re-entered the throwing getter and the exception escaped. 3. The replacement StreamWriter did not set AutoFlush, while Console.Out is created with AutoFlush = true, so output smaller than the 64 byte buffer was silently dropped. Console.In / Console.Out / Console.Error are now each evaluated once inside a guard, with readers/writers that keep stdin/stdout open, auto-flush and fall back to UTF-8 (or TextReader.Null) when the console is unavailable. The non UTF-16/UTF-8 writer replacement is gone: it provided no benefit and dropped the synchronized wrapper Console.Out normally has.
This branch has not been deployed
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
1 participant
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.
Problem
SharedIO.InitializeInput()accessesConsole.InputEncodingwithout error handling. On Russian Windows this returns cp866, but in hosting environments like Dynamo (Autodesk Revit) or on .NET Core, the codepage data is unavailable, causing:This crashes
Python.CreateEngine()in IronPython.Fix
Added
TryGetConsoleEncoding()helper that wraps console encoding access in try-catch with fallback:Applied to
SupportLevel.Fullcase in:InitializeInput()—Console.InputEncoding→ fallbackEncoding.UTF8InitializeOutput()—Console.Out.Encoding→ fallbackEncoding.UTF8InitializeErrorOutput()—Console.Error.Encoding→ fallbackEncoding.UTF8Companion PR
This fix works together with IronLanguages/ironpython2#851 which adds
Encoding.RegisterProvider(CodePagesEncodingProvider.Instance)inPythonContextstatic constructor for .NET Core/Standard.Testing
Verified with C# host simulating Dynamo environment — all tests pass.