Language runtimes shouldn't support #Windows.
-
Language runtimes shouldn't support #Windows. It buggers up pathnames, and wrapping them in some arbitrary object to get around Windows' brokenness just makes it more difficult than it needs to be on any sane OS.
-
@dickon They shouldn't pretend that pathnames are strings, either., so what's the alternative?
-
@dickon They shouldn't pretend that pathnames are strings, either., so what's the alternative?
@hillu Why not? '/' and '\0' are the only forbidden bytes in an element name; looks pretty stringy to me.
Not Unicode, no.
-
@hillu Why not? '/' and '\0' are the only forbidden bytes in an element name; looks pretty stringy to me.
Not Unicode, no.
@dickon You seem to favor treating pathnames as bytebuffers, then.
Forward slashes are not forbidden as part of pathnames, of course. And whether valid UTF-8 sequences are required (or that is ignored altogether) is very much related to what the filesystem implements. -
@dickon You seem to favor treating pathnames as bytebuffers, then.
Forward slashes are not forbidden as part of pathnames, of course. And whether valid UTF-8 sequences are required (or that is ignored altogether) is very much related to what the filesystem implements.@hillu re '/': yes, hence the 'element name'. But I've never met a Unix filesystem which requires valid UTF-8 sequences, and this causes problems when your APIs can't process them cleanly; whether I like this or not doesn't really matter. Personally I hate spaces in object names as that causes problems all over the shop. But I have to deal with that.
Windows had a whole class of vulnerabilities around creating a C:\Program.exe at one point. I don't know if that was ever completely sorted.
-
@hillu re '/': yes, hence the 'element name'. But I've never met a Unix filesystem which requires valid UTF-8 sequences, and this causes problems when your APIs can't process them cleanly; whether I like this or not doesn't really matter. Personally I hate spaces in object names as that causes problems all over the shop. But I have to deal with that.
Windows had a whole class of vulnerabilities around creating a C:\Program.exe at one point. I don't know if that was ever completely sorted.
@dickon I wholeheartedly agree with you that the Windows side is very messy.
An example for a UNIX filesystem that has thoughts about Unicode is APFS. -
@dickon I wholeheartedly agree with you that the Windows side is very messy.
An example for a UNIX filesystem that has thoughts about Unicode is APFS.@hillu Interesting; I should have expected Apple to do something like that. https://eclecticlight.co/2021/05/08/explainer-unicode-normalization-and-apfs/ suggests it's actually HFS+ that did, and APFS doesn't, relying instead on some other layer. I'd be fascinated to see what happens if you try that sort of trick in Terminal.app, over NFS, and using the usual POSIX APIs in a small C program. I don't have a Mac to hand, unfortunately.
-
@hillu Interesting; I should have expected Apple to do something like that. https://eclecticlight.co/2021/05/08/explainer-unicode-normalization-and-apfs/ suggests it's actually HFS+ that did, and APFS doesn't, relying instead on some other layer. I'd be fascinated to see what happens if you try that sort of trick in Terminal.app, over NFS, and using the usual POSIX APIs in a small C program. I don't have a Mac to hand, unfortunately.
@dickon If you try to produce ifiles with invalid UTF-8 sequences, you'll get an EINVAL error if memory serves correctly.
-
R relay@relay.infosec.exchange shared this topic
