On 2022-11-10 10:19, Aaron Ballman wrote:
In terms of the Clang side of things, I don't think we've formed any sort of official stance on how to handle that yet. It's UB (you can declare the C standard library interface without UB but calling any function with a mismatched signature is UB)
The Autoconf-generated code is never executed, so this is not a runtime issue; it's merely an issue of undefined behavior during translation. A problem could occur with a picky compiler or linker that rejects modules with mismatched function type declarations. Does Clang do that, or require or use such a linker? If not, there's no practical problem here. If so, it'd be helpful if Clang continued to support its traditional behavior that doesn't reject Autoconf's test cases, and for this to be the default.
Autoconf arose because one cannot ask something like "Can I call the renameat2 function with its usual signature?" in standard C code and one must escape into something like the shell to handle such questions. C23 and GCC and Clang have added a few features to answer such questions, such as __has_include. But these features don't go nearly far enough. For example, __has_include tells me only whether the include file <foo.h> exists; it won't tell me whether I can successfully include <foo.h>, or whether <foo.h> will declare the function 'bar', or whether 'bar' will have a signature compatible with my code's calls to 'bar'.
If I could request a single thing from the C23/GCC/Clang side, I'd ask for better facilities to be able to ask such questions within C code, without using the shell. Then a good chunk of Autoconf could dry up and blow away.
I realize that I'm asking for a lot. For example, a traditional implementation cannot answer the renameat2 question without consulting the linker. That being said, this ability is essential for modular programming at the low level, and if compilers don't provide this ability Autoconf will simply have to do the best it can, regardless of whether it generates source code that relies on undefined behavior.
