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?
CVE-2006-1174 is a possibly reasonable example.
CVE-2006-1174 is not an example, because no prototype 'char foo(void);' was involved.[1]
Here's a more concrete proposal that should allay any realistic concerns about CVEs. If Clang decides to change its behavior in this area, so that Clang starts to exit with nonzero status if the user declares a function with a prototype incompatible with the C library, it would be a service to real users if Clang merely issues a warning and does *not* error out if the declaration is 'char foo();' (current Autoconf) or 'char foo(void);' (future Autoconf).
This may be a hack, but it's a *good* hack. It's likely to fix real-world bugs that would be caused if Clang becomes overly pedantic by default here. And the probability of introducing real-world bugs is essentially zero.
You can run into that same bug with use of `-Werror`
That's OK, as the Autoconf documentation already says "don't do that". And if Clang exits with nonzero status in the above situation when -Werror is specified, that's fine too.
[1] CVE-2006-1174 is not even an example of prototype mismatch, as the bad C code did not misdeclare the function in question: it used a POSIX standard include file for the function prototype, which is the standard way to do things.
