On 2022-11-10, Zack Weinberg <zack@xxxxxxxxxxxx> wrote: > The biggest remaining (potential) problem, that I’m aware of, is that > AC_CHECK_FUNC unconditionally declares the function we’re probing for > as ‘char NAME (void)’, and asks the compiler to call it with no > arguments, regardless of what its prototype actually is. It is not > clear to me whether this will still work with the planned changes to > the compilers. Both GCC 12 and Clang 14 have on-by-default warnings > triggered by ‘extern char memcpy(void);’ (or any other standard > library function whose prototype is coded into the compiler) and this > already causes problems for people who run configure scripts with > CC='cc -Werror'. Unfortunately this is very hard to fix — we would > have to build a comprehensive list of library functions into Autoconf, > mapping each to either its documented prototype or to a header where > it ought to be declared; in the latter case we would also have to make > e.g. AC_CHECK_FUNCS([getaddrinfo]) imply AC_CHECK_HEADERS([sys/types.h > sys/socket.h netdb.h]) which might mess up configure scripts that > aren’t expecting headers to be probed at that point. > > How important do you think it is for this to be fixed? My gut feeling is that Autoconf should just determine the necessary options to get compatible behaviour out of these modern compilers, at least for the purpose of running configure tests. For example, Autoconf should probably build the AC_CHECK_FUNC programs using gcc's -fno-builtin option, which should avoid problems with gcc complaining about memcpy (and may also improve test accuracy, since gcc won't use its knowledge of C library behaviour to possibly elide the call to memcpy). It saddens me to see so much breakage happening in "modern C", a language that has (until now) a long history of new language features being carefully introduced to avoid these sort of problems. The fact that even the C standard authors don't even seem to care about existing codebases is a concerning change in direction. Nobody has learned anything from the Python 3 debacle, I guess. > p.s. GCC and Clang folks: As long as you’re changing the defaults out > from under people, can you please also remove the last few predefined > user-namespace macros (-Dlinux, -Dunix, -Darm, etc) from all the > -std=gnuXX modes? Meh, even though these macros are a small thing I don't accept the "things are breaking anyway so let's break even more things" attitude. This was something that many library authors did during the python 3 transition and that just made the problems orders of magnitude more horrible. Cheers, Nick
