[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Lynx-dev] Re: Standards compliance..? (Was Re: non-pkgsrc emacs or clon

From: Marc Tooley
Subject: [Lynx-dev] Re: Standards compliance..? (Was Re: non-pkgsrc emacs or clone)
Date: Wed, 25 May 2005 14:56:50 -0700
User-agent: KMail/1.8

On Wednesday 25 May 2005 12:44, David Maxwell wrote:
> On Wed, May 25, 2005 at 11:07:37AM -0700, Marc Tooley wrote:
> > I'm pretty sure there was a NetBSD commit to fix mkdir() (and other
> > calls) so they worked with a trailing slash, in violation of the
> > Single UNIX Standard which states that all trailing slashes must be
> > interpreted as "/." everywhere. Many applications made assumptions
> > about it apparently, because it "just worked" on so many other
> > platforms.
> Nope. The SUS didn't specify the behaviour in the case of mkdir,
> because the argument to mkdir(2) is not (yet) a directory, it's a
> name for which you wish to create a directory.
> So, the decision was easy to make - compatibility, given that no
> standard had to be violated.

According to the following poster's idea, a strict interpretation of the 
Pathname Resolution section would cause mkdir("foo/") to fail:

... and the author there (presumably following the concept of an OS for 
applications and not the other way around) requested a modification to 
conform to applications' common use of the trailing slash in a 
pathname, recognising the need for such behaviour to make it easier for 
programmers to write their applications.

Subsequent to that, rather than marking the item as a defect and 
causing, in their view, "damage to the industry" someone piped up to  
clarify the definition:

The check-in fixing this for NetBSD happened in September 2003, 
according to PR/15397. The dates on the above documents are in November 
2003 and later, so there was still debate even in the Open Group (and 
the world at large) as to what the interpretation of the pathname 
resolution was, post-NetBSD commit. It was enough to result in Proposed 
Interpretation AI-016.

My point is we went ahead did it anyway to accommodate historical usage 
and the application developers even in the face of a *potential* 
standards violation.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]