On 11/17/22 13:35, Bruno Haible wrote:
Clang will surely not acquire knowledge about "every library", right,
only about the C library according to relevant standards (ISO C, POSIX)?
I don't know the Clang developers' plans. But if I wanted Clang to be
picky then yes, I'd have it know about ev
On 2022-11-16 10:59, Zack Weinberg wrote:
I'm generally in agreement with Rich Felker's argument
(inhttps://ewontfix.com/13/) that AC_CHECK_FUNC*should not* just probe for
linkability of a symbol
So am I. I'm not saying Autoconf should never change here, only that the
change would not be tr
On 2022-11-16 10:40, Jeffrey Walton wrote:
This line of arguments is not persuasive. It is full of logical fallacies.
... none of which you stated.
No matter how we solve the problem, it will be a hack that exploits
"logical fallacies" (whatever that means). However, a reaction "You
violated
On 2022-11-16 06:26, Michael Matz wrote:
char foobar(void);
int main(void) {
return &foobar != 0;
}
That still has undefined behavior according to draft C23, which says
behavior is undefined when foobar is (say) 'memset_explicit' because the
declaration 'char memset_explicit(void);' disagr
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 p
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
On 2022-11-15 06:50, Jonathan Wakely wrote:
Could you clarify what you mean, with a concrete example? Surely as
long as errors are reported on stderr and the compiler exits with
non-zero status, that's an acceptable way to report errors?
Not if the "error" is harmless as far as Autoconf is conc
On 2022-11-14 04:41, Aaron Ballman wrote:
it's generally a problem when autoconf relies on invalid
language constructs
Autoconf *must* rely on invalid language constructs, if only to test
whether the language constructs work. And Clang therefore must be
careful about how it diagnoses invalid
On 2022-11-11 07:11, Aaron Ballman wrote:
Clang doesn't require such a linker (we work with various system linkers).
As long as the system linkers continue to work as they have
traditionally worked, we're fine.
the frontend perspective, we can't tell the difference between
"trust me this is
On 2022-11-11 07:11, Aaron Ballman wrote:
We believe the runtime behavior is sufficiently dangerous to
warrant a conservative view that any call to a function will be a call
that gets executed at runtime, hence a definitive signature mismatch
is something we feel comfortable diagnosing (in some f
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
On 2022-11-10 09:16, Zack Weinberg wrote:
Changes to handle C23 built-in ‘bool’ better are under development but
the design has not yet been finalized.
[I'm cc'ing this to bug-gnulib too.]
To my mind this is the biggest outstanding issue in Autoconf as far as
C23 goes, as the upgrade path for
12 matches
Mail list logo
