On Mar 1 12:03, Corinna Vinschen via austin-group-l at The Open Group wrote: > On Feb 29 17:27, Austin Group Bug Tracker via austin-group-l at The Open > Group wrote: > > ====================================================================== > > Summary: Must posix_getdents remember file offsets across > > exec? > > ====================================================================== > > [...] > > Likewise, the behavior is unspecified if in between two calls to > > <i>posix_getdents</i>() on one file descriptor, the file offset is altered > > by a call made on a different file descriptor that refers to the same open > > file description and the new offset is not zero.</blockquote> > > While the new clarifications look mostly good to me, this snippet still > looks like a problem, in particular the restriction "and the new offset > is not zero". > > The reason is that after dup, the process has to create a new DIR > for the dup'ed descriptor. The two DIR's are logically distinct. > > The above paragraph sounds like the behaviour is not supposed to be > undefined in the follwoing situation: > > posix_getdents (fd1, ...); // file pos != 0 after this call > > fd2 = dup (fd1); > > lseek (fd2, SEEK_SET, 0); // seeks file to pos 0 via fd2 > > posix_getdents (fd1, ...); // is now supposed to start at pos 0? > > If so, I'm not sure how to do this via underlying DIR pointer. > > The DIR pointer attached to fd1 is either dropped from or duplicated > to fd2. It's certainly not the same DIR pointer. The lseek in > fd2 can only affect the DIR attached to fd2, not the one from fd1. > > So, given we don't have a seekable underlying OS file descriptor, > how is the second posix_getdents on fd1 supposed to know that it > has to restart at pos 0?
I added this as a note to issue 1798. Thanks, Corinna
