std.file functions and embedded NUL characters [CWE-158]

[Steven Schveighoffer]

On Sunday, 3 August 2025 at 00:03:47 UTC, kdevel wrote:
> On Friday, 1 August 2025 at 17:53:17 UTC, Steven Schveighoffer 
> wrote:
>> [...]
>> It's always a fight between correctness and performance here.
>
> Pardon?

I mean in terms of where you apply the checks. You can say "I 
expect you to have validated this before sending it in", or you 
can say "I will always validate this, even if you already have, 
in the name of correctness."

And I suppose a better word should have been "tradeoff" and not 
"fight".

>
>> [...]
>> I'm not sure that's the library's responsibility. In other 
>> words, if I pass in `rmdir("foo")`, then why should I pay the 
>> penalty of examining `"foo"` for malicious NUL bytes?
>
> The `NUL` is not representable in `char *`. But all phobos 
> filesystem functions use unadorned `string` parameters for 
> pathnames. Who else if not the designer of the library shall be 
> responsible for coding (not paying!) the extra cpu cycles?
>
> If the library expects pathnames without embedded `NUL`s I 
> would create a subtype of `string`, say `fstring` or `cstring`. 
> One then has to discuss which of these calls

The issue is going to be fixed, not sure if you saw my issue 
report. It's quite an easy fix actually.

But just so you know, C also allows passing in C strings with 
embedded null characters:

```c
#include <unistd.h>

int main() {
    rmdir("hello\0world");
    return 0;
}
```

And we do expose `core.stdc.posix.unistd`.

-Steve