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
Paul Eggert wrote:
> > AC_CHECK_FUNC *should not* just probe for linkability of a symbol
>
> ... Autoconf cannot
> be expected to know every signature of every function in every library.
Clang will surely not acquire knowledge about "every library", right,
only about the C library according to
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
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
On Sat, Nov 12, 2022 at 7:44 PM Paul Eggert wrote:
> 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
Hello,
On Wed, 16 Nov 2022, Paul Eggert wrote:
> On 2022-11-16 06:26, Michael Matz wrote:
> > char foobar(void);
> > int main(void) {
> >return != 0;
> > }
>
> That still has undefined behavior according to draft C23,
This is correct (and also holds for the actually working variant later,
On Wed, Nov 16, 2022, at 1:17 PM, Paul Eggert wrote:
...
> If Clang's threatened pickiness were of some real use elsewhere, it
> might be justifiable for default Clang to break Autoconf. But so far we
> haven't seen real-world uses that would justify this pickiness for
> Autoconf's use of 'char
On Wed, Nov 16, 2022 at 1:18 PM Paul Eggert wrote:
> ...
> If Clang's threatened pickiness were of some real use elsewhere, it
> might be justifiable for default Clang to break Autoconf. But so far we
> haven't seen real-world uses that would justify this pickiness for
> Autoconf's use of 'char
On 2022-11-16 06:26, Michael Matz wrote:
char foobar(void);
int main(void) {
return != 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);' disagrees
On Wed, 16 Nov 2022 at 16:34, Michael Matz wrote:
>
> Hello,
>
> On Wed, 16 Nov 2022, Jonathan Wakely wrote:
>
> > > > Unrelated but I was a bit tempted to ask for throwing in
> > > > -Wbuiltin-declaration-mismatch to default -Werror while Clang 16 was at
> > > > it, but I suppose we don't want
Hello,
On Wed, 16 Nov 2022, Jonathan Wakely wrote:
> > > Unrelated but I was a bit tempted to ask for throwing in
> > > -Wbuiltin-declaration-mismatch to default -Werror while Clang 16 was at
> > > it, but I suppose we don't want the world to burn too much,
> >
> > :-) It's IMHO a bug in the
On Wed, 16 Nov 2022 at 15:59, Michael Matz wrote:
>
> Hello,
>
> On Wed, 16 Nov 2022, Sam James wrote:
>
> > Unrelated but I was a bit tempted to ask for throwing in
> > -Wbuiltin-declaration-mismatch to default -Werror while Clang 16 was at
> > it, but I suppose we don't want the world to burn
Hello,
On Wed, 16 Nov 2022, Sam James wrote:
> Unrelated but I was a bit tempted to ask for throwing in
> -Wbuiltin-declaration-mismatch to default -Werror while Clang 16 was at
> it, but I suppose we don't want the world to burn too much,
:-) It's IMHO a bug in the standard that it misses
On Wed, 16 Nov 2022, Michael Matz via Gcc wrote:
> 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
> On 16 Nov 2022, at 15:27, Richard Biener wrote:
>
> On Wed, Nov 16, 2022 at 4:02 PM Michael Matz via Gcc wrote:
>>
>> Hey,
>>
>> On Wed, 16 Nov 2022, Alexander Monakov wrote:
>>
The idea is so obvious that I'm probably missing something, why autoconf
can't use that idiom
On Wed, Nov 16, 2022 at 4:02 PM Michael Matz via Gcc wrote:
>
> Hey,
>
> On Wed, 16 Nov 2022, Alexander Monakov wrote:
>
> > > 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
Hey,
On Wed, 16 Nov 2022, Alexander Monakov wrote:
> > 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?
>
> Ironically, modern GCC and LLVM optimize ' != 0'
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
>
On Tue, Nov 15, 2022 at 15:09:19 -0800, Paul Eggert wrote:
> 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.
FWIW,
On Tue, 15 Nov 2022, Sam James wrote:
On 13 Nov 2022, at 00:43, Paul Eggert wrote:
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,
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
On Tue, Nov 15, 2022 at 3:27 PM 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
On Tue, Nov 15, 2022 at 2:08 PM Paul Eggert wrote:
>
> 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
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
On Tue, 15 Nov 2022 at 19:08, Paul Eggert wrote:
>
> 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
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
On Mon, 14 Nov 2022 at 18:15, Paul Eggert wrote:
>
> 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
> On 15 Nov 2022, at 13:30, Zack Weinberg wrote:
>
> On Tue, Nov 15, 2022, at 12:03 AM, Sam James wrote:
>>> On 13 Nov 2022, at 00:43, Paul Eggert wrote:
>>>
>>> Although there will be problems with people who run "./configure
>>> CFLAGS='-Werror'", that sort of usage has always been
On Tue, Nov 15, 2022, at 12:03 AM, Sam James wrote:
>> On 13 Nov 2022, at 00:43, Paul Eggert wrote:
>>
>> Although there will be problems with people who run "./configure
>> CFLAGS='-Werror'", that sort of usage has always been problematic and
>> unsupported by Autoconf, so we can simply
> On 13 Nov 2022, at 00:43, Paul Eggert wrote:
>
> 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
* Paul Eggert:
> 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
On Mon, Nov 14, 2022 at 1:14 PM Paul Eggert wrote:
>
> 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.
On Sat, Nov 12, 2022 at 7:43 PM Paul Eggert wrote:
>
> 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
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
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
Demi Marie Obenour writes:
> On 11/10/22 15:19, Paul Eggert wrote:
>> Here's the main Autoconf issue issue with bool. Traditionally, Autoconf
>> supported K C, C89, C99, etc. At some point (I'm not sure when),
>> Autoconf started requiring C89 or later. Is it now OK for Autoconf to
>>
On Thu, Nov 10, 2022 at 4:05 PM Paul Eggert wrote:
>
> 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
> On 10 Nov 2022, at 17:16, Zack Weinberg wrote:
>
> I’m the closest thing Autoconf has to a lead maintainer at present.
>
> It’s come to my attention (via https://lwn.net/Articles/913505/ and
> https://fedoraproject.org/wiki/Changes/PortingToModernC) that GCC and
> Clang both plan to disable
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
41 matches
Mail list logo
