On Sun, 10 Jun 2018 23:57:35 +0200, Peter J. Holzer wrote:

> I think this is worth keeping, and "I couldn't pass that file name to
> the OS" is a different error than "the OS told me the file doesn't
> exist", so I think it should be a different exception.

What makes you think that NUL bytes are a fundamental limitation that no 
OS could every cope with?

Classic Mac OS takes file names as Pascal strings, with a length byte and 
an array of arbitrary bytes, no NUL terminator required. Despite what far 
too many C programmers appear to believe, NUL-terminated strings are not 
a fundamental requirement.

Navigating Apple's documentation is a nightmare, but I've found the 
deprecated Carbon file manager APIs. For example, creating a file with 
PBCreateFileUnicodeSync:

https://developer.apple.com/documentation/coreservices/1566896-
pbcreatefileunicodesync?language=objc

takes a FSRefParam argument:

https://developer.apple.com/documentation/coreservices/fsrefparam?
language=objc

which includes a name field which is a pointer to an array of Unicode 
characters, and a separate name length.

The evidence suggests that using the Carbon APIs, NUL is just another 
Unicode character. Whatever API replaces Carbon, it will have to deal 
with file names created under Carbon, and classic Mac, and so likely will 
support the same.

Baking a limitation of some file systems into the high-level interface is 
simply a *bad idea*. There is no good reason to treat file names 
containing NUL as special in the API (even if, for implementation 
reasons, it has to be treated specially in the implementation).

How would you feel if there were a whole lot of ignorant Pascal 
programmers arguing that it was fundamentally impossible for file names 
to exceed 255 characters, and therefore os.path.exists() out to raise 
ValueError when passed a file name of 256 characters?

"But it is impossible to pass a string of 256 characters to the OS" is no 
more foolish than "it is impossible to pass a string with an embedded NUL 
to the OS". Both are implementation details. Neither should be baked into 
the high-level language as a fundamental requirement.



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

-- 
https://mail.python.org/mailman/listinfo/python-list

Reply via email to