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

[Peter Moulder]

On Sun, Jun 15, 2003 at 12:05:42AM +1000, Simon Taylor wrote:

> +	% '/' on Unix systems and '\' on Microsoft Windows systems.

Any opinions as to whether to say '\' or '\\' or `\' or backslash ?
'\' jars a little, but I'm not sure that it isn't the best option.
I'd lean towards `/' and `\'.

> +	% dir__split_name(PathName, DirName, BaseName).
> +	% Split a filename into a directory part and a filename part.
> +	% Fails for root directories or relative filenames not
> +	% containing a directory separator.

I think the usual thing people want from something outputting DirName
and BaseName is p(X, dirname(X), basename(X)), and I think such a
procedure should be provided; though such a predicate could be called
dir__dirname_basename if we also want something with the proposed
split_name semantics.  (Off hand I can't think of a case where a program
would want the proposed semantics.)

I think that if we use the names dirname and basename then we should try
to conform to a fairly authoritative standard for these names, say

 http://www.opengroup.org/onlinepubs/007904975/functions/dirname.html
 http://www.opengroup.org/onlinepubs/007904975/functions/basename.html

(However, the existing implementation doesn't for a few cases like
"/", "", or when PathName has trailing slashes.)

I'm no expert on Windows filename semantics.  Would basename("C:\\") =
"\\" be reasonable?  Are there comparable standards for functions with
these names under Windows?

> +	% dir__basename(PathName) = BaseName.
> +	% Returns the directory part of a filename.
> +:- func dir__dirname(string) = string is det.

Copy & paste problem.


I think the documentation for the dir foldl preds should say something
about order.  For the recursive versions, it's worth specifying that
parents are processed before their children.  For children, perhaps
state that there are no order guarantees.  I'm tempted to specify that
it's the same order as given by the underlying platform's
directory-reading function.  (This has useful properties for many
filesystems, in some cases even lexical ordering.)

The NEWS file says `for iterating through the entries of a directory'
(which to me means all the entries regardless of file type), whereas the
individual predicate descriptions say only [symlinks to] subdirectories.


check_for_symlink_loop: I wonder whether it would be better to use
set_bbbtree rather than list, on grounds of optimizing for worst case;
the usual case has acceptable performance for either representation.


The name `follow_symlink' to me suggests that it acts recursively (finds
the ultimate destination if it's a symlink to a symlink to a ...),
whereas the implementation is not recursive.  The predicate
documentation doesn't clearly specify -- though I would guess that
`pointing to' isn't recursive.

I think the name of the predicate is significant because it's what
people reading existing code see, and this distinction can lead to
rarely-noticed bugs that could have security implications.  I think
io__readlink is an acceptable name given that it's the name used on all
systems I know of that do support symlinks.


Should io__file_id documentation say anything about following symlinks?


Is anyone else tempted to implement flags with:

  [] = 0.
  [Flag | Flags] = mask(Flag) \/ Flags.

?  No, I guess it's just me.

pjm.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------