Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 23 Feb 2021 15:16:31 -0500
From: Rich Felker <>
To: enh <>
Cc: Florian Weimer <>,
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 <> 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.


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.