4 ms·
I would assume that what author meant by this is that on Unix for the kernel itself names of various entities (filenames and similar things) are simply sequence
by dfox 7y ago
I would assume that what author meant by this is that on Unix for the kernel itself names of various entities (filenames and similar things) are simply sequences of bytes that it does not ordinarily try to interpret in any way. (On the other hand SUS specifies that only very limited set of characters is valid in filename, but no "true unix" actually cares about that)
On Windows NT filename is specified as sequence of 16 bit wchar_ts and is supposed to be valid NFC UTF-16. OS X also expects that filenames are valid sequences of unicode codepoints and in this case NFD.
- ChrisSD 7y ago> On Windows NT filename is specified as sequence of 16 bit wchar_ts and is supposed to be valid NFC UTF-16. I would emphasise that the "supposed to be" is a convention only (similar to the Linux UTF-8 convention). The only filesystem enforced rules are that file/directory names can't include \/:*?"<>| or wchar_t(s) less than 0x20 (aka ascii control characters). A Win32 path can also have additional rules (such as a file cannot be called "COM") but these aren't always enforced, depending on how the API is called.
- unascribed 7y agoYes, that was the intent. C itself obviously just sees chars as a number, but in C itself strings have no real meaning at all. The fact the kernel treats them as opaque byte sequences is the important part.