Ben Rudiak-Gould wrote:
Symbolic links complicate things a bit, since they are followed like edges but are actually paths.
Actually, they're essentially arbitrary byte strings. The OS doesn't automatically require them to be valid paths. Most of the API functions to which you might pass a symbolic link will fail if they don't contain a valid path. But not all; e.g. lstat() and readlink() work regardless. So far as invalid symlinks are concerned, the main issue is that programs don't die horribly just because they "encounter" an invalid symlink (as opposed to trying to actually "use" one).
Then of course there's the issue that Win32 edge labels are Unicode, while Posix edge labels are [Word8]. Hmm.
Strictly speaking, they're [CChar], but I doubt that anyone will ever implement Haskell on a platform where a byte isn't 8 bits wide.
pathToForeign :: p -> IO (Ptr CChar) pathFromForeign :: Ptr CChar -> IO p
This interface is problematic. Is the pointer returned by pathToForeign a heap pointer which the caller is supposed to free? If so, a Ptr CChar instance would have to copy the pathname every time. And I don't understand exactly what pathFromForeign is supposed to do.
I presume that it's meant to be the fundamental un-marshalling
function for the Path class. But it seems Unix-specific; on Windows,
filenames wouldn't normally be converted to CChars.
--
Glynn Clements