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. > >
Basically. 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. Cheers, Derek _______________________________________________ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs