[m-rev.] for review: library changes for `mmc --make' on Windows

[Fergus Henderson]

On 15-Jul-2003, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> On 15-Jul-2003, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > On 15-Jul-2003, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> > > We're coming at this from different angles. My opinion is that
> > > a path name should conceptually be an abstract type. Any user
> > > code depending on the presence or absence of slashes on the end
> > > of a directory name is broken.  In the same way, user code can't
> > > assume anything about directory separators in the paths returned
> > > from the dir module.
> > 
> > But directory names and path names are strings.  So they are not abstract.
> > 
> > An important operation that you might want to do with such names
> > is to write them to a file which might be used by another program.
> > That other program might not be written in Mercury, and might
> > behave differently depending on whether the directory name has
> > a trailing slash.
> 
> In which case that program is buggy -- the filesystem doesn't care
> about the trailing slash, so any program which does is wrong.

I'm afraid that's not true.

Saying that "the filesystem doesn't care about the trailing slash"
ignores the point that some important APIs (e.g. the .NET CLI, /bin/ls,
etc.) do care.

Also, the external program in question might concatenate a directory name
and a file name, and then expect the resulting string to be a valid path.
If the directory name does not have a trailing slash, this won't give
the correct results.  But that doesn't mean that the external program
is buggy; maybe the external program's specification said that directory
names in its configuration file should end with a trailing slash.

Equally, the external program might concatenate a directory name, a
slash, and a file name.  If the directory name already has a trailing
slash, the resulting path name will have two slashes, which may not give
correct results -- even on Unix platforms.  Suppose, for example, that
the external program is "make".  A rule for "foo//bar" is no match for
a target "foo/bar", and vice versa.  Is that a bug in make?
No, make conforms to the Posix standard.

If the Mercury standard library leaves these things unspecified,
it would be easy for a Mercury programmer to accidentally rely on
unspecified behaviour when writing path names to a configuration file.
Such bugs might not show up at all until much later, when the Mercury
program was being ported to run on a different platform (e.g. .NET CLR
instead of Win32).  They might also be hard to track down, if the
consequences did not make it immediately obvious, because the subtle
difference of a missing or additional slash would be easy to miss.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------