Date: Thu, 5 Sep 2019 14:17:39 -0400
On Thu, Sep 5, 2019 at 1:54 PM Tom Honermann <tom_at_[hidden]> wrote:
> On 9/5/19 12:17 PM, Niall Douglas wrote:
> >
> > There is no reason why POSIX, or Win32, might not support NUL in
> > filenames in the future. Especially if C introduces a lengthed string.
> I disagree that there is no reason. The reason is that supporting this
> requires all new interfaces. I don't see that happening.
> >
>
>
Ironically, we have UTF-8 because of a desire for a file system safe
encoding that disallowed aliasing path separator and nul.
A forklift upgrade of the file system apis is not in the realm of
possibility, even if C provided a string type that allows embedded nuls.
Every program that processes paths is vulnerable to attack with unexpected
nuls. Even if POSIX provided APIs it would be fantastically unlikely that
vendors would allow their customers to be broken that way, because the old
APIs can't be turned off.
> On 9/5/19 12:17 PM, Niall Douglas wrote:
> >
> > There is no reason why POSIX, or Win32, might not support NUL in
> > filenames in the future. Especially if C introduces a lengthed string.
> I disagree that there is no reason. The reason is that supporting this
> requires all new interfaces. I don't see that happening.
> >
>
>
Ironically, we have UTF-8 because of a desire for a file system safe
encoding that disallowed aliasing path separator and nul.
A forklift upgrade of the file system apis is not in the realm of
possibility, even if C provided a string type that allows embedded nuls.
Every program that processes paths is vulnerable to attack with unexpected
nuls. Even if POSIX provided APIs it would be fantastically unlikely that
vendors would allow their customers to be broken that way, because the old
APIs can't be turned off.
Received on 2019-09-05 20:17:52