Hi,
On Tue, 15 Nov 2022, Paul Eggert wrote:
> On 2022-11-15 11:27, Jonathan Wakely wrote:
> > Another perspective is that autoconf shouldn't get in the way of
> > making the C and C++ toolchain more secure by default.
>
> Can you cite any examples of a real-world security flaw what would be
> found by Clang erroring out because 'char foo(void);' is the wrong
> prototype? Is it plausible that any such security flaw exists?
>
> On the contrary, it's more likely that Clang's erroring out here would
> *introduce* a security flaw, because it would cause 'configure' to
> incorrectly infer that an important security-relevant function is
> missing and that a flawed substitute needs to be used.
>
> Let's focus on real problems rather than worrying about imaginary ones.
I sympathize, and I would think a compiler emitting an error (not a
warning) in the situation at hand (in absence of -Werror) is overly
pedantic. But, could autoconf perhaps avoid the problem? AFAICS the
ac_fn_c_check_func really does only a link test to check for symbol
existence, and the perceived problem is that the call statement in main()
invokes UB. So, let's avoid the call then while retaining the access to
the symbol? Like:
-----
char foobar(void);
int main(void) {
return &foobar != 0;
}
-----
No call involved: no reason for compiler to complain. The prototype decl
itself will still be "wrong", but compilers complaining about that (in
absence of a pre-existing different prototype, which is avoided by
autoconf) seem unlikely.
Obviously this program will also say "foobar exists" if it's a data
symbol, but that's the same with the variant using the call on most
platforms (after all it's not run).
The idea is so obvious that I'm probably missing something, why autoconf
can't use that idiom instead. But perhaps the (historic?) reasons why it
couldn't be used are gone now?
Ciao,
Michael.
