segfault on macOS 26.3 when compiled against SDK 26.4 #229

Hello!

Steps to Reproduce

Environment: macOS 26.3.1 (build 25D2128, Darwin 25.3.0), arm64, Apple clang 17.0.0.
Reproduced on 4.1.2 installed from Homebrew and on current main (0cd3d15) built from source.

$ SDKROOT=/path/to/MacOSX26.4.sdk ./configure
$ SDKROOT=/path/to/MacOSX26.4.sdk make
...
$ mkdir -p /tmp/t/a/b
$ ./bin/bfs /tmp/t -maxdepth 1 -type d ; echo "exit=$?"   # exit=0, prints fine
$ ./bin/bfs /tmp/t -type d             ; echo "exit=$?"   # exit=139 (SIGSEGV on descent)

Building against the 26.2 SDK produces a correct binary. The crash appears only the moment bfs descends into a subdirectory; -maxdepth 1 is fine.

Commentary

config.h diff shows fdclosedir is the sole difference:

$ make clean && ./configure --enable-release; cp gen/config.h /tmp/config-262.h
$ make clean && SDKROOT="$SDK264" ./configure --enable-release; cp gen/config.h /tmp/config-264.h
$ diff /tmp/config-262.h /tmp/config-264.h)
25c25
< #define BFS_HAS_FDCLOSEDIR false
---
> #define BFS_HAS_FDCLOSEDIR true

<dirent.h> in the 26.4 SDK declares it as introduced in 26.4:

int fdclosedir(DIR *) __API_AVAILABLE(macos(26.4));   // MacOSX26.4.sdk/usr/include/dirent.h:176

The configure probe build/has/fdclosedir.c only checks that the symbol compiles and links. Against the 26.4 SDK this links (the symbol is weak-imported), but at runtime on 26.3.x the symbol is absent and resolves to NULL, so directory descent segfaults.

The compiler already flags this during the probe build, but the warning is non-fatal so the probe ignores it:

warning: 'fdclosedir' is only available on macOS 26.4 or newer [-Wunguarded-availability-new]
note: ... introduced in macOS 26.4 here, but the deployment target is macOS 26.0.0
note: enclose 'fdclosedir' in a __builtin_available check to silence this warning

The fix should probably be to beef up the configure check (as a fallback path exists), or to gate the symbol at runtime on macOS.

I didn't submit a PR because I didn't observe any existing pattern in the repo for either solution, but am happy to do so with guidance.

—
Assisted-by: Claude Code (Claude Opus 4.8)