access()

[Guy Harris]

>What does ANSI say about the filename argument passed to the access()
>function? Especially with regard to directorys.

ANSI sayeth not Bugger All about it, for it is a UNIX function and not a
C function.

POSIX, however, sayeth:

	"pathname".  A string that is used to identify a *file*.  It
	consists of, at most, {PATH_MAX} bytes, including the
	terminating null character.  It has an optional beginning
	*slash*, followed by zero or more *filenames* separated by
	*slashes*.  If the *pathname* refers to a *directory*, it may
	also have one or more trailing *slashes*.

(*word* here indicates that "word" appears in italics in the original).

I read this as saying that anything claiming POSIX conformance had
better allow trailing slashes; I presume this means "foo/" is equivalent
to "foo", if "foo" is a directory.

 >For example, in RCS there are statements like
 >	access("./RCS/", 000)
 >
 >But under a supposedly ANSI compiler (MSC 5.1) these lines return an
 >error that says RCS/ does not exist when RCS/ is fine.
 >
 >If the filename is "RCS" everything is just fine, and the proper
 >response is returned.
 >
 >Is this the correct behavior?

Well, It Depends.  I suspect MSC 5.1 does not claim POSIX conformance,
so in that sense the behavior is at least permissible; it may be
undesirable, and whether it's "correct" or not depends on your
definition of "correct".

The intent of the MSC library is presumably to provide some level of
UNIX compatibility.  There are a number of different standards that
purport to define various levels of UNIX compatibility; they say
different things about trailing slashes.  The System V Interface
Definition, for example, seems to indicate that trailing slashes are not
valid in pathnames, so a SVID-compliant implementation of "access" need
not handle them as you would like.  POSIX indicates, as I read it, that
they are valid in pathnames, so a POSIX-compliant implementation must
handle them as you would like.

In any case, I think you should remove trailing slashes where possible,
in case you run across an implementation that doesn't handle them as
you'd like; I also think you have some claim that MSC should handle
them, and should note this to Microsoft.