|
Message-ID: <20210223201631.GA32655@brightrain.aerifal.cx> 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.