[Top][All Lists]

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

Re: windows-NT/pwd.c - struct passwd - Home Directory

From: Derek Price
Subject: Re: windows-NT/pwd.c - struct passwd - Home Directory
Date: Wed, 01 Jun 2005 10:15:38 -0400
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

Conrad T. Pino wrote:

>My ideas for the API are UNIX/POSIX specifications are non-negotiable and
>internal APIs below that are discardable upon discovery of the better way.


In theory, you could take up desired changes with the POSIX spec with
IEEE.  Of course, if you did get some changes through, it would likely
be years before we could support them fully in CVS and GNULIB - that
doesn't happen until it is determined that hosts which require older
(i.e. POSIX2) specifications are no longer reasonable porting targets. 
As an example, GNULIB and CVS both still support ANSI C89
specifications.  I would not hazard a guess as to when C99 will be
judged a reasonable assumption.  GNULIB just finally dropped support for
SunOS 4.1.4, about a year and a half after Sun did.  Of course, the
official policy of GNULIB is to drop support when the provider of the OS
does, but it isn't always noticed right away.

Also, for a traget like Windows, compliance may be "as close as
possible" to the POSIX spec.  Sometimes a POSIX spec will make reference
to other POSIX specs, and if, for instance, the getpwuid spec referenced
the /etc/passwd file directly, we might only be able to approximate the
desired result.  What you and I are debating, I think, is what is
morally closest to the POSIX spec on Windows.

As an aside, it might sometimes be interesting to look at what Cygwin
did in some of these cases.  Their code is GPL'd.  Of course, I've
looked at it before, and it tends to be much too involved to import into
CVS easily - they have their own userid system overlaid on top of
Windows, for instance, which would likely make getpwuid a challenge to
import, and similar things happen with their file descriptor
implementation, but something like their implementation of usleep() or
nanosleep() might not have so many internal dependencies.



reply via email to

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