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 |