Sounds great, good observations. Absent any other opinions, with that
resolved, I'm happy to tag and roll this afternoon to begin the release
vote.
On Fri, Mar 29, 2019, 04:26 Yann Ylavic wrote:
> On Fri, Mar 29, 2019 at 5:01 AM William A Rowe Jr
> wrote:
> >
> > Opinions?
>
> Anyway, our
On Fri, Mar 29, 2019 at 5:01 AM William A Rowe Jr wrote:
>
> Opinions?
Anyway, our usage of readdir_r() is no more thread-safe than with the
non-_r() version, because of the (struct dirent *)thedir->entry we
pass to it (should be either on the stack or allocated for each
apr_dir_read() call), or
Yes, that patch is option 2... and I would be alright with that choice.
Looking for consensus on which way we resolve this.
Opinions?
On Thu, Mar 28, 2019, 10:55 Yann Ylavic wrote:
> On Thu, Mar 28, 2019 at 4:19 PM William A Rowe Jr
> wrote:
> >
> > So... What is our preferred solution as of
On Thu, Mar 28, 2019 at 4:55 PM Yann Ylavic wrote:
>
> On Thu, Mar 28, 2019 at 4:19 PM William A Rowe Jr wrote:
> >
> > So... What is our preferred solution as of 1.7.0?
> >
> > 1. Drop readdir[64]_r for readdir[64] always.
> > 2. Allow readdir[64]_r with an autoconf toggle, skip detection.
> >
So to this question, glibc 2.24 is the first release to loudly deprecate
readdir_r.
https://www.sourceware.org/ml/libc-alpha/2016-08/msg00212.html
However, the docs summary mentioned below calls out reasons why readdir_r
was never a good thing.
So... What is our preferred solution as of 1.7.0?
