[SG16-Unicode] P1689: Encoding of filenames for interchange
Steve Downey
sdowney at gmail.com
Thu Sep 5 20:17:39 CEST 2019
On Thu, Sep 5, 2019 at 1:54 PM Tom Honermann <tom at honermann.net> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open-std.org/pipermail/unicode/attachments/20190905/3b029dfe/attachment.html
More information about the Unicode
mailing list