[Haskell-cafe] RE: ANN: System.FilePath 0.9

[Brian Smith]

[ I tried to send this through the fa.haskell USENET group but apparently it
did not go through]

I kind of expect that a Haskell library for file paths will use the
type system to ensure some useful properties about the paths.

For example, when writing security-conscious software I often want to be
able to distinguish between absolute, ascending (paths with leading
"../" and similar items), and decending paths (paths that contain no
"../").

I want to make sure a filename is valid. For example, "prn" and "con"
are not valid path elements for normal files on Windows, certain
characters are not allowed in filenames (depending on platform), some
platforms may require paths to be escaped in different ways. I see
there is a "isValid" function and even a (magical) "makeValid"
function, but they do not report what was wrong with the filename in
the first place. Furthermore, it isn't clear from the documentation how
these functions determine whether a filename is valid.

Many people might be familiar with Joel Spolsky's article "Making Wrong
Code Look Wrong" at http://www.joelonsoftware.com/articles/Wrong.html .
If you read that article, you will see that advocates a variable naming
convenctions to distinguish between HTML-escaped "safe" and non-escaped
"unsafe" strings. In Haskell, we can do much better than that by using
convenient strong static typing to enforce such constraints. We should
be able to use type signatures to ensure that we are operating on
syntactically valid paths of a certain form. For example, a function's
type should indicate that it expects an absolute path, or a relative
path that doesn't use "../../.." to decend into parent/sibling
directories unexpectedly, which is a common exploit technique.

IMO, safety is the most important issue regarding file paths and it is
not addressed in this library as far as I can see. Writing code to
handle these issues is tedious, error-prone, and boring to write
despite being critical. It isn't the kind of code that you want to just
download off of some guy's webpage. Basically, it is exactly the type
of thing that belongs in a standard library.

In this library proposal, there are a bunch of "xxxDrive" functions
that many Unix-oriented programmers are sure to ignore because they are
no-ops on Unixy systems. Even on Windows, they are not very useful:
Windows software almost never cares what drive a directory is on,
especially because the directory might not be on a drive at all (for
example, a UNC network path "\\foo\bar" has no "drive" component but it
is an absolute path). Really, Windows software usually works similarly
to Unixy software in this regard--the big difference is that Unixy
systems have one root path, whereas Windows systems can have many, many
root paths (drives and UNC's).
- Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org//pipermail/haskell-cafe/attachments/20060716/be904bcf/attachment-0001.htm