Izumi Tsutsui <tsutsui@ceres.dti.ne.jp> writes:
> In article <20020428194117.GA19591@night-porter.duskware.de>
> martin@duskware.de wrote:
> > > I've heard that POSIX does not require to accept trailing slash
> > > for directory pathname. It's optional, so I think it is not a bug,
> > > and userland applications should not assume it is always acceptable.
> >
> > This is wrong, according to Klaus Klein (our standards guru).
> > There even is a regression test in src/regress that checks for this (and
> > currently fails).
> 
> I've heard POSIX say pathname _may_ have trailing slash,
> and application which is strictly complient with POSIX
> should not use features mentioned "may" in standard.
> But I don't know whether kernel should support it for compliancy.

This is why the IETF has MAY and may, to distinguish between the
normative use ("MAY") designating an optional feature, and the
conventional English language use ("may").  Not every "may" in the
POSIX standard indicates an optional feature; this is particularly
true in the preliminary sections covering definitions and general
concepts (where the text in question occurs).  Those sections deal
with definitions of *terms*, not definitions of interface features.  A
UNIX pathname, after all, isn't a feature--it is a fundamental concept
of the system.

So, for example, under "pathname resolution" POSIX says

    There may be multiple pathnames that resolve to the same file.

Does this mean that multiple pathnames are an optional feature?  Can't
be, link(2) isn't optional.  This is the conventional use of "may",
indicating that there can exist multiple pathnames to the same file
(which an implimentation must support), not the normative use that
would indicate that support for multiple pathnames need not be
implemented.

Similarly, where the definition of "pathname" says:

    If the pathname refers to a directory, it may also have one or
    more trailing slashes.

this says that the definition of a valid directory pathname includes
the possibility of traliing slashes, which the implimentation must
handle--not that an implimentation need not support trailing slashes.

But even if it were optional, that isn't a good argument for not
supporting it.  For example, under POSIX supporting the ',' character
in filenames is optional--comma isn't in the portable filename
character set.  Is that a compelling argument for NetBSD to not
support commas in filenames?  POSIX also says

    As a special case, in the root directory, dot-dot may refer to the
    root directory itself.

So I guess having /.. a link to / is optional, but I don't think
getting rid of /.. (or having it point somewhere else) would be a good
idea.

-- 
"The mere tendency of speech to encourage unlawful acts is not a
sufficient reason for banning it. [...]  The right to think is the
beginning of freedom, and speech must be protected from the government
because speech is the beginning of thought."  --Anthony Kennedy