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\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).
Trac metadata
Trac field | Value |
---|---|
Version | 8.0.2 |
Type | Bug |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | libraries/base |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture |