I don't understand your comment about @deftypefun.
Sorry, I meant to complain about this paragraph
(https://sourceware.org/git/?p=glibc.git;a=blob;f=manual/filesys.texi;h=edc7c64d22169bfb9f104321b141a6b4925ce740;hb=38efe8c5a5c1676f54481caa81980a93f7223479#l509):
# In POSIX.1-2008, @code{readdir} is not thread-safe. In @theglibc{}
# implementation, it is safe to call @code{readdir} concurrently on
# different @var{dirstream}s, but multiple threads accessing the same
# @var{dirstream} result in undefined behavior. @code{readdir_r} is a
# fully thread-safe alternative, but suffers from poor portability (see
# below). It is recommended that you use @code{readdir}, with external
# locking if multiple threads access the same @var{dirstream}.
which should really be something like
# @strong{Caution:} The pointer returned by @code{readdir} points to
# a buffer within the @code{DIR} object. The data in that buffer will
# be overwritten by the next call to @code{readdir}. You must take care,
# for instance, to copy the @code{d_name} string if you need it later.
#
# Because of this, it is not safe to share a @code{DIR} object among
# multiple threads, unless you use your own locking to ensure that
# no thread calls @code{readdir} while another thread is still using the
# data from the previous call. In @theglibc{}, it is safe to call
# @code{readdir} from multiple threads as long as each thread uses
# its own @code{DIR} object. POSIX.1-2008 does not require this to
# be safe, but we are not aware of any operating systems where it
# does not work.
#
# @code{readdir_r} allows you to provide your own buffer for the
# @code{struct dirent}, but it is less portable than @code{readdir}, and
# has problems with very long filenames (see below). We recommend
# you use @code{readdir}, but do not share @code{DIR} objects.
with matching changes made to the readdir_r documentation. If we
clarified the text along those lines I'd be fine with calling readdir
thread-safe in the annotations.