Tail after and including `NUL` character in `FilePath`s silently truncated
The current behaviour is imho not ideal as it masks invalid input arguments; consider e.g.
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" are equivalent, as both are interpreted as
What I'd expect to happen on POSIX systems is that operations taking a
FilePath such as
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).