Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!bionet!apple!longway!std-unix From: rml@hpfcdc.hp.com (Bob Lenk) Newsgroups: comp.std.unix Subject: Re: Standards Update, 1003.1 System services interface Message-ID: <394@longway.TIC.COM> Date: 6 Sep 89 23:06:42 GMT References: <386@longway.TIC.COM> Sender: std-unix@longway.TIC.COM Reply-To: Bob Lenk Lines: 55 Approved: jsq@longway.tic.com (Moderator, John S. Quarterman) Cc: gwyn@BRL.ARPA, donn@hpfcdc.hp.com, jsq@hpda.hp.com From: Bob Lenk In article <386@longway.TIC.COM> gwyn@brl.arpa (Doug Gwyn) writes: > In article <384@longway.TIC.COM> std-unix@uunet.uu.net writes: > >.... Supplement B also includes symbolic links, truncate(), ftruncate(), > >putenv(), clearenv(), getpass(), seekdir(), telldir(), chroot(), fchmod(), > >fchown(), and fsync(). > > We deliberately left seekdir() and telldir() out of IEEE Std 1003.1, > because they cannot be reliably implemented in all reasonable UNIX-based > environments. I wish people would quite trying to second-guess the > original work. The list of functions looks roughly like the list included in the draft (I believe numbered 0) that was brought into the April meeting as a basis for discussion. It included essentially the union of all functions people at the prior meeting had considered including. At the April meeting the working group actually decided to exclude several functions from the supplement, including seekdir() and telldir() (also getpass() and chroot()). While seekdir() and telldir() were certainly considered during the drafting of the original 1003.1 standard, good rationale for omitting them was never captured; Appendix B outlines a technique to use in place of these functions, but that technique is no more (perhaps even less) portable than seekdir()/telldir(). The topic was the subject of some significant discussion during balloting, and not resolved to everyone's satisfaction. At the April meeting the Working Group agreed that the real need was for a portable means to traverse file trees in processes with limited file descriptors, and is pursuing a solution based loosely on ftw(). The draft of revsion 1003.1a, currently being balloted, adds rationale for exclusion of these functions (as well as getpass() and chroot()). The two most recent proposals on file tree traversal are in the August P1003.1 mailing. The current direction seems to be based on the idea of ftopen(), ftread(), and ftclose() outlined at the end of the Fowler-Korn-Vo proposal (P1003.1/N172). I expect this to be discussed at length at the next meeting (October in Brussels), and possibly subsequent meetings. While the USENIX Standards Watchdog Committee and this forum are certainly useful, they are no substitute for direct participation in the committees themselves, either as a source of timely and accurate information or as a mechanism for providing input. In particular, the single sentence about functions in Supplement B is far from a complete account of the topic, and should not be expected to be one. Of course all of the above represents only my opinions and recollections. Bob Lenk rml@hpfcla.hp.com hplabs!hpfcla!rml Volume-Number: Volume 17, Number 24