On Thu, Sep 11, 2025 at 09:45:19AM -0600, Alan Somers wrote:
> On Thu, Sep 11, 2025 at 9:01 AM Dag-Erling Smørgrav <d...@freebsd.org> wrote:
>
> > Alan Somers <asom...@freebsd.org> writes:
> > > Dag-Erling Smørgrav <d...@freebsd.org> writes:
> > > > Tell that to the Rust developers. They have been repeatedly warned
> > > > against using readdir_r(3) for years, as far back as 2016.
> > > Have they? Looking at rust's github page, I see discussions about
> > > using readdir_r on Fuchsia and Linux, but nothing about BSD.
> >
> > If you look at these tickets, there are people pointing out that
> > readdir_r() doesn't work correctly even on platforms where it isn't
> > formally deprecated. The Rust developers chose to fix the Linux case
> > because it produced a link-time warning and ignored the rest. That's on
> > them.
> >
> > They also seem to be providing their own prototype for readdir_r(),
> > which suppresses the deprecation warning they should be getting on
> > FreeBSD 15, and turns the issue from a failure to compile into a failure
> > to link. That's also on them.
> >
>
> Where do you see that? I suppose you must be talking about this line in
> libc. That's not due to anything special about readdir_r; it's just the
> way that Rust links to _every_ libc function. There is a CI step that
> ensures these FFI definitions are accurate.
> https://github.com/rust-lang/libc/blob/61b722e2517775cea98428702710ee9ef00f02a0/src/unix/mod.rs#L1769C22-L1769C23
>
>
> >
> > > possibly with the aid of installing misc/compat14x
> >
> > That won't make any difference since readdir_r() is still in our libc.
> >
> > DES
> > --
> > Dag-Erling Smørgrav - d...@freebsd.org
> >
>
> There's another problem that we haven't discussed, which is the ability to
> run older Rust toolchains. Even if we fix Rust 1.89.0 to no longer use
> readdir_r, older versions will continue to do so. And Rust developers
> frequently must test with older toolchains. For example, any change to
> Rust's libc requires testing with version 1.63.0, released in August 2022.
> We can't remove readdir_r without breaking all of those workflows. We
> could probably remove the prototype, but not the function itself.
Binaries that were succesfully linked, continue to work.
If you take any binary that already used readdir_r@FBSD_1.5, it is
unchanged. Symbol is there, but the default version of it not.
