Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!eecae!netnews.upenn.edu!rutgers!cbmvax!uunet!auspex!guy From: guy@auspex.UUCP (Guy Harris) Newsgroups: comp.lang.c Subject: Re: access() Message-ID: <979@auspex.UUCP> Date: 9 Feb 89 11:45:46 GMT References: Reply-To: guy@auspex.UUCP (Guy Harris) Distribution: comp Organization: Auspex Systems, Santa Clara Lines: 51 >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.