#10762: On Windows, out-of-codepage characters can cause GHC build to fail ---------------------------------+----------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6037 | Differential Revisions: ---------------------------------+----------------------------------------- Comment (by snoyberg): After this discussion, here's the proposal I'd make, which is a libraries change, not just a GHC-internal change: * The default filesystem encoding will always be UTF-8, regardless of environment variables or codepage * We modify the encoding logic on Windows to also respect an environment variable (perhaps LANG, not sure) to override the codepage for stdin/stdout/stderr character encoding One I'm on the fence about: * Modify the character encoding codepaths to not throw an exception on an unhandled character when using the default encoding for stdin/stdout/stderr. This would be nice in that GHC wouldn't die on printing a warning if the codepage/LANG variable is set to something unusual, but does have the property of just swallowing problematic behavior. I'm fairly certain that will solve the major problems we have with GHC, and will fit the stack use case nicely. Does anyone else reading see a problem with this approach before I bring it up with the core libraries committee? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10762#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler