stddef.h is unused, commit da88b16a221c9d327e1bfa61dd6f4f08dacce57a removed the use of offsetof().
calling qsort() with a pointer to a function whose type is not compatible with int(const void *, const void *) results in UB because qsort() would call this function with an incompatible type. avoid this by using qsort_r(). this is similar to how qsort() is implemented on top of qsort_r(). the types of the pointers passed to wrapper_cmp() are struct dirent *const * but the caller's comparison function expects const struct dirent **. copy the pointer values into local variables and pass their addresses to the caller's comparison function to get the right type and avoid aliasing violations. this is only necessary because the pointer to the comparison function for scandir() was (incorrectly) specified as int (*)(const struct dirent **, const struct dirent **) rather than int (*)(struct dirent *const *, struct dirent *const *).
if the loop is exited because len * sizeof *names does not fit into size_t, errno should be explicitly set to ENOMEM. previously, the behavior differed depending on which value errno happened to have at this point. if cnt reached a value > INT_MAX, scandir() returned an incorrect value. EOVERFLOW should be reported instead. it's unlikely that these errors can actually occur. it may not even be possible to have directories with that many entries, and even then malloc() or realloc() will probably fail long before len or cnt reach those large values.
opendir() or closedir() might act upon a cancellation request. because scandir() did not disable cancellation or install a cancellation cleanup handler, this could lead to memory and file descriptor leaks.
when closedir() set errno, scandir() misinterpreted this as a failure. this was wrong for two reasons: * if closedir() succeeds, errno could still have been set, e.g. by __aio_close(). * even if closedir() "fails", it always closes the file descriptor and frees memory, so there is no reason to free all directory entries and return from scandir() with a failure.
POSIX.1-2024 requires that standard functions don't set errno to 0. commit dae17a1aaf25d8333e729173d86659066607d87d ensured that cmp() and the caller of scandir() cannot observe that errno is set to 0 internally. however, this was not yet the case for the sel() callback.
commit 1b0d48517f816e98f19111df82f32bfc1608ecec wrongly copied the getdents return type of int rather than matching the ssize_t used by posix_getdents. this was overlooked in testing on 32-bit archs but obviously broke 64-bit archs.
this interface was added as the outcome of Austin Group tracker issue 697. no error is specified for unsupported flags, which is probably an oversight. for now, EOPNOTSUPP is used so as not to overload EINVAL.
originally the namespace-infringing "large file support" interfaces were included as part of glibc-ABI-compat, with the intent that they not be used for linking, since our off_t is and always has been unconditionally 64-bit and since we usually do not aim to support nonstandard interfaces when there is an equivalent standard interface. unfortunately, having the symbols present and available for linking caused configure scripts to detect them and attempt to use them without declarations, producing all the expected ill effects that entails. as a result, commit 2dd8d5e1b8ba1118ff1782e96545cb8a2318592c was made to prevent this, using macros to redirect the LFS64 names to the standard names, conditional on _GNU_SOURCE or _LARGEFILE64_SOURCE. however, this has turned out to be a source of further problems, especially since g++ defines _GNU_SOURCE by default. in particular, the presence of these names as macros breaks a lot of valid code. this commit removes all the LFS64 symbols and replaces them with a mechanism in the dynamic linker symbol lookup failure path to retry with the spurious "64" removed from the symbol name. in the future, if/when the rest of glibc-ABI-compat is moved out of libc, this can be removed.
fdopendir is specified to fail with EBADF if the file descriptor passed is not open for reading. while O_PATH is an extension and arguably exempt from this requirement, it's used, albeit incompletely, to implement O_SEARCH, and fdopendir should fail when passed an O_SEARCH file descriptor. the new check is performed after fstat so that we don't have to consider the possibility that the fd is invalid. an alternate solution would be attempting to pre-fill the buffer using getdents, which would fail with EBADF for us, but that seems more complex and error-prone and involves either code duplication or refactoring, so the simple fix with an additional inexpensive syscall is what I've made for now.