| Casper H.S. Dik 2007-02-22, 7:19 am |
| unix_fan <tmellman@web.de> writes:
>See quote above. In particular *It
> shall also cause the directory stream to refer to the current state of
> the corresponding directory, as a call to opendir() would have done*
Yes, so?
>Where is this documented? ... Oh. You mean the disk i/o isn't done at
>rewinddir() time, but rather at readdir() time ... in this one case.
And in the opendir() case as well; opendir() does not read from directories.
>Okay. That could be. (But it's still a specification bug, because it
>proscribes how the implementation has to be done. IMHO, it would be
>cleaner not to overload the readdir() with special case operations. If
>an implementation wanted to do the dir read at rewind time, it'd have
>to store the error message up in order to deliver it later, at the
>readdir() time).
readdir() is not overloaded with special cases.
Each *dir() operation will leave the DIR* in a specific state for:
- offset in the directory stream is at
- amount of buffered data
- offset of where the buffered data was read
Both opendir and rewinddir make sure the offset of the directory is 0
and the amount of buffered data is 0 too.
(During the lifetime of readdir(), not having buffered data available
happens multiple tmes)
>Yes, but both cases don't list the actual read of the directory - which
>in the scenario you're describing is now in a rewinddir/readdir pair.
I did not list the reads because opendir/closedir/rewinddir do not
cause reads; they do not need to read data so they do not read data.
Only readdir calls read() (or really getdents())
It's just like bufferend file operations.
fopen() opens the file but reads no data, just like opendir.
fseek() discards buffered data but reads none, just like seekdir/rewinddir
fread() reads data into a buffer and returns some as requested, just
like readdir().
Casper
|