On Tue, Nov 04, 2025 at 11:03:17AM -0500, Zack Weinberg wrote: > To elaborate on "not conveniently", this _is_ something that we would like to > fix in the long run. WASM is not the only environment that has started > complaining about this extremely old-school code, and I expect it to become > more of a problem as more compilers adopt C2024 (in which 'extern char strnlen > ()' arguably ought to provoke a hard error from the _compiler_, not just the > linker, whether or not <string.h> has been included). > > However, the only plausible way to fix it is for Autoconf to have a giant > table listing, for each function that AC_CHECK_FUNC is likely to be asked to > check for, the header that is supposed to declare it, and the expected > prototype. At a minimum this table should should cover all of ISO C and all > of POSIX, including functions that _used_ to be in either standard but have > been removed. You can probably imagine how much work this would be, and none > of the core Autoconf maintainers have the time to tackle it in the near > future.
Such a built-in database doesn't really fit with the Autoconf philosophy. Murphy will ensure that whenever you try to use this feature the database will always be missing at least one function you are trying to test. Maybe it could be workable if Autoconf punted to the user to supply all the required database entries for each configure script. AC_CHECK_FUNC and friends have always been too simplistic and fraught with false negatives, the only real difference is that this is happening in more popular build environments nowadays. Configure script authors should simply avoid these problematic macros entirely and always use AC_LINK_IFELSE with a test program that provides realistic calls and declarations. In other words: this particular bug should be fixed in gmp. Cheers, Nick
