#13660: Tail after and including `NUL` character in `FilePath`s silently truncated -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.0.2 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The current behaviour is imho not ideal as it masks invalid input arguments; consider e.g. {{{#!hs Prelude> readFile "foo" *** Exception: foo: openFile: does not exist (No such file or directory) Prelude> readFile "foo\NULbar" *** Exception: foobar: openFile: does not exist (No such file or directory) Prelude> writeFile "foo\NULbar" "contents" Prelude> readFile "foo\NULbar" "contents" Prelude> readFile "foo" "contents" }}} The reason for the surprising behaviour above is most likely (I haven't yet looked at the code), that `"foo\NULbar"` gets converted into a zero- terminated `CString` which is then passed to C functions such as `fopen(3)`, but to those C function, the C strings `"foo\0bar"` and `"foo"` are equivalent, as both are interpreted as `"foo"`. What I'd expect to happen on POSIX systems is that operations taking a `FilePath` such as `writeFile` or `readFile` should throw an exception when the `FilePath` gets encoded in such a way into a zero-terminated CString in such a way that a zero octet occurs (except for the intended zero-termination zero octet at the end). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13660 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler