configure script misdetects compiler built-ins as available functions

[Un1q32]

The configure script sometimes has false positives for functions like strnlen where the compiler does optimizations to remove it's use.

As you can see here when the configure script's strnlen test is built with a modern clang with optimizations enabled, it is optimized to a simple return 0, since clang knows about strnlen and knows that if the function is working properly it will always succeed.

The solution is to build those feature tests with -fno-builtin, which disables optimizations related to known functions in the standard library.

[magicant]

If your libc supports strnlen, the function will work as expected regardless of whether clang inlines it or not, so it is a true positive.
If your libc does not provide strnlen and clang still performs inlining based on clang's built-in implementation, probably it is a bug in clang.

[Un1q32]

If your libc does not provide strnlen and clang still performs inlining based on clang's built-in implementation, probably it is a bug in clang.

The configure script's code provides a function definition, the godbolt snippet is taken directly from the configure script, including the function definition. That check will always succeed in the compile phase as long as string.h is in include path, regardless of what it contains, on a sane libc that doesn't support strnlen it can only fail in the link phase. Clang does have a list of libcs/versions and what builtin functions they contain, but that is only used for when it wants to replace code snippets with a call to a builtin, eg replacing an inline copy loop with a memcpy. When inlining calls like it is here, it only checks if the function signature is correct.