🚀 go-pugleaf

From: Bob Lenk <rml@hpfcdc.hp.com>

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