  = note: ld: error: undefined symbol: readdir_r
          >>> referenced by std.d8968a002452916e-cgu.07
          >>>               std-de94806a57729acc.std.d8968a002452916e-cgu.07.rcgu.o:(std::sys::fs::unix::remove_dir_impl::remove_dir_all_recursive::hbe1160129d2c5f7c) in archive /wrkdirs/usr/ports/lan
g/rust/work/bootstrap/lib/rustlib/x86_64-unknown-freebsd/lib/libstd-de94806a57729acc.rlib
          >>> did you mean: readdir_r@FBSD_1.5
          >>> defined in: /lib/libc.so.7
          cc: error: linker command failed with exit code 1 (use -v to see invocation)

In D52474#1198528, @markmi_dsl-only.net wrote:

This broke building rust 1.88 via poudriere-devel :

That's a bug in rust. Two bugs, actually: using readdir_r() in the first place, and using it despite the lack of a prototype.

des added a reverting change: rGd20c82507278: Revert "libc: Remove readdir_r(3)".Sep 11 2025, 3:12 PM

Small suggestion for when/if this gets recommitted.

By the way, I think the current warning message about readdir_r() in the man page is likely wrong. Looking at all implementations of VOP_PATHCONF() in sys/fs, UFS and ZFS, I only see constants being returned except for the NFS client, where that entirely depends on the server (which is actually wrong given our implementation of namei()). While I can easily conceive that different directories may have different values (e.g., if not backed by the same FS), I have a harder time imagining that this value would change *while* a directory is in use, and some POSIX wording implies this cannot be the case. The reason for deprecating readdir_r() seems to be that it cannot be used on systems where {NAME_MAX} is indeterminate (pathconf() returning -1 on _SC_NAME_MAX), which is not the case on FreeBSD.

Based on this, I do not think that readdir_r() poses any actual security problems on FreeBSD, and thus see no hurry in removing this function (even if less efficient). Do you agree?