How can Autoconf help with the transition to stricter compilation defaults?

[Paul Eggert via cfe-commits]

>> 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.