[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 23 Feb 2021 15:16:31 -0500
From: Rich Felker <dalias@...c.org>
To: enh <enh@...gle.com>
Cc: Florian Weimer <fweimer@...hat.com>, libc-coord@...ts.openwall.com
Subject: Re: Lifetime of object returned by readdir
On Tue, Feb 23, 2021 at 12:10:42PM -0800, enh wrote:
> On Tue, Feb 23, 2021 at 10:32 AM Florian Weimer <fweimer@...hat.com> wrote:
>
> > > POSIX already explicitly says that seekdir() affects the _next_
> > > readdir().
> >
> > That's because it's the only way its effect is observable.
> >
> > The glibc implementation of seekdir performs an immediate seek, but if
> > the seek fails, that error is not really observable (except for reading
> > the implementation and inferring that the errno = 0 hack will work). I
> > had not realized that seekdir returns void. Maybe that argues in favor
> > of a delayed seek upon the next readdir call.
> >
> > > does anyone have an implementation where rewinddir()/seekdir()
> > > actually invalidate the previous readdir()? seems unlikely?
> >
> > Probably not. But there's also the issue of fitting the directory
> > offset (usually off64_t, maybe even something larger) into the long int
> > return value of telldir, so there could be quite a bit of magic going on
> > in the background (considering that telldir cannot indicate failure).
> >
>
> i suspect anyone iterating over a directory that large has other problems
> :-)
No, the problem is that the kernel's internal iterator is potentially
a 64-bit opaque token not an offset in a linear directory table,
depending on the filesystem in use. This may need translation on archs
where long is 32-bit in order for seekdir/telldir to work right. But
that's a separate topic.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
