Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!udel!haven!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: question on opendir, readdir, etc.
Message-ID: <14616@smoke.brl.mil>
Date: 30 Nov 90 10:02:50 GMT
References: <4767@rossignol.Princeton.EDU> <14611@smoke.brl.mil> <4776@rossignol.Princeton.EDU>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 39

In article <4776@rossignol.Princeton.EDU> tr@samadams.princeton.edu (Tom Reingold) writes:
>Which is obsolete?  <sys/ndir.h>?

All forms of directory access that bypass getdents() are obsolete.
Basically, you should use only the <dirent.h> form of opendir()/
readdir()/closedir() or some library function that is layered on top
of those.  seekdir()/telldir() are not recommended.

>How can it work?  And why was this kludge put there?

What do you mean, how can it work?  If you look at the sources you
said you have, you should see that there is actually more storage
present than one might guess from just looking at the struct dirent.
The line of argumentation that ties wording in the C standard to
exploitation of this trick is rather long and involved, and would
not be worth rehashing yet again here.  (Besides, everyone involved
in the argument, including me, has flip-flopped a couple of times on
the issue of whether a conforming implementation is obliged to make
the trick work.  In practice, it can normally be expected to work,
so this is a purely academic issue.)

The reason for the kludge (more a "trick") is that it was desired
to not allocate a maximum-length array for a directory entry, but
rather just as much storage as was really necessary.

>$ You can also obtain my current implementation simply by requesting it
>$ in an e-mail message to me <Gwyn@BRL.MIL>.
>I have it already, thank you.  Now I know I should use it.

Make sure you have a recent release.  Some of the versions in
circulation have a couple of subtle bugs in them (use of a field
in a free()d structure in closedir(), and a problem with 14-character
entries in the UFS version of getdents()).

>Is this POSIX standard found in System V Release 4?

UNIX System V Release 4.0 attempts to be IEEE Std 1003.1 compliant.
The <dirent.h> facilities are specified in the current SVID, so
naturally they are in SVR4.