-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
#98441 - Ignore invalid handle/access when setting console cp #98641
Conversation
There are situations where setting the console code page is expected to fail. For instance, if the application was started with DETACHED_PROCESS, the attempting to set the code page will fail with ERROR_INVALID_HANDLE. In these cases, ignore the returned error. Fix dotnet#98441
Tagging subscribers to this area: @dotnet/area-system-console Issue DetailsThere are situations where setting the console code page is expected to fail. For instance, if the application was started with DETACHED_PROCESS, the attempting to set the code page will fail with ERROR_INVALID_HANDLE. In these cases, ignore the returned error. Fixes #98441
|
@dotnet-policy-service agree company="National Instruments" |
Is it possible to add a test? |
coding conventions: use explicit Type rather than var Co-authored-by: Jan Kotas <jkotas@microsoft.com>
This helps ensure GetLastError is called immediately after the failing win32 function.
@jkotas : Yes, but only if the test is allowed to start a new project. I put a short crash sequence in the work item thread. |
Yeah - I should have updated this thread. I'm currently working on a couple tests for this issue. It took a little bit of time to aquaint myself with the test infrastrucure. It looks to me like the existing Do we agree that tests with Edit: to be clear, the |
Either If you would like to go with |
Tests added. I went with FreeConsole. I like the way the test you linked to re ran the process with custom flags - pretty cool. |
// The internal state of Console should have updated, despite the failure to change the console's input encoding | ||
Assert.Equal(encoding, Console.InputEncoding); | ||
// Operations on the console are no longer valid - GetConsoleCP fails. | ||
Assert.Equal(0u, GetConsoleCP()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would advise testing that Console.WriteLine() still works here. The caller would need to use StandardOutputRedirected = true for the test case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Thank you
The test is failing on Windows Nano Server:
|
I see why the test is failing. The code asserts that the current output codepage is not the one it's going to try to test by changing it to. So the test knows it doesn't work and bails. Looks like the test harness needs to handle that case. Clearly the implementation needs to be if already 65001 use some other codepage instead of 65001. I'm not sure which code page it should change to though. Code page 437 would be a sane choice everywhere else but I'm not sure about nano. |
Any one of the built-in .NET encodings should work: runtime/src/libraries/System.Private.CoreLib/src/System/Text/Encoding.cs Lines 208 to 215 in 1b1d26a
|
Updated to ensure we set an encoding that's different from whatever is existing. Also updated two existing tests that were not performing such a check. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thank you @nick-beer for providing not just the fix but also great tests!
There are situations where setting the console code page is expected to fail. For instance, if the application was started with DETACHED_PROCESS, the attempting to set the code page will fail with ERROR_INVALID_HANDLE. In these cases, ignore the returned error.
Fixes #98441