bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How can Autoconf help with the transition to stricter compilation de


From: Paul Eggert
Subject: Re: How can Autoconf help with the transition to stricter compilation defaults?
Date: Tue, 15 Nov 2022 15:09:19 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]