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 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'
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
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, 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,
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,
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
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.
* 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 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 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-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
Wookey writes:
> On 2022-11-10 19:08 +0100, Florian Weimer wrote:
>> based on a limited attempt to get this fixed about three years
>> ago, I expect that many of the problematic packages have not had their
>> configure scripts regenerated using autoconf for a decade or more. This
>> means that
On 2022-11-10 19:08 +0100, Florian Weimer wrote:
> * Zack Weinberg via Gcc:
>
> > 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 several “legacy” C language features by
>
Sam James writes:
>> On 12 Nov 2022, at 03:40, Zack Weinberg wrote:
>> This is definitely more work than I can see myself doing on a volunteer
>> basis, but a 2.69.1 patch release — nothing that’s not already on trunk,
>> cherry pick the changes needed to support the newer compilers (and
>>
Paul Eggert writes:
> On 2022-11-10 19:33, Zack Weinberg wrote:
>
>> It would be relatively easy for me to take a couple hours this
>> weekend and put out a 2.72 release with everything that's already in
>> trunk and nothing else. Anyone have reasons I _shouldn't_ do that?
>
> I don't have
> On 12 Nov 2022, at 00:53, Paul Eggert wrote:
>
> On 2022-11-11 15:25, Sam James wrote:
>> That's not a judgement on whether the changes will ultimately remain in
>> autoconf, I'm just
>> hesitant to allow a discussion I've kicked off to derail something that we
>> were planning
>> on doing
On Fri, 11 Nov 2022, Zack Weinberg via Gcc wrote:
> These are also a trip hazard for novices, and the only way to turn them
> off is with -std=cXX, which also turns another trip hazard (trigraphs)
> *on*… so yeah, anything you can do to help speed up their removal, I
> think it’d be worthwhile.
> On 12 Nov 2022, at 03:40, Zack Weinberg wrote:
>
> Florian Weimer writes:
>> based on a limited attempt to get this fixed about three years
>> ago, I expect that many of the problematic packages have not had their
>> configure scripts regenerated using autoconf for a decade or more. This
Florian Weimer writes:
> based on a limited attempt to get this fixed about three years
> ago, I expect that many of the problematic packages have not had their
> configure scripts regenerated using autoconf for a decade or more. This
> means that as an autoconf maintainer, you unfortunately
Rich Felker writes:
> On Thu, Nov 10, 2022 at 12:16:20PM -0500, Zack Weinberg wrote:
>> The biggest remaining (potential) problem, that I’m aware of, is that
>> AC_CHECK_FUNC unconditionally declares the function we’re probing for
>> as ‘char NAME (void)’, and asks the compiler to call it with no
Nick Bowler writes:
> My gut feeling is that Autoconf should just determine the necessary
> options to get compatible behaviour out of these modern compilers, at
> least for the purpose of running configure tests. For example, Autoconf
> should probably build the AC_CHECK_FUNC programs using
On 2022-11-11 15:25, Sam James wrote:
That's not a judgement on whether the changes will ultimately remain in
autoconf, I'm just
hesitant to allow a discussion I've kicked off to derail something that we were
planning
on doing anyway.
What do you think?
I'm hesitant to do that partly
> On 11 Nov 2022, at 03:33, Zack Weinberg wrote:
>
> On Thu, Nov 10, 2022, at 10:08 PM, Sam James wrote:
>>> On 10 Nov 2022, at 21:10, Michael Orlitzky wrote:
>>> While everyone else is discussing big ideas, it would be helpful for me
>>> personally if autoconf just made a release with the
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 11 Nov 2022, at 03:33, Zack Weinberg wrote:
>
> On Thu, Nov 10, 2022, at 10:08 PM, Sam James wrote:
>>> On 10 Nov 2022, at 21:10, Michael Orlitzky wrote:
>>> While everyone else is discussing big ideas, it would be helpful for me
>>> personally if autoconf just made a release with the
On Thu, Nov 10, 2022, at 10:08 PM, Sam James wrote:
>> On 10 Nov 2022, at 21:10, Michael Orlitzky wrote:
>> While everyone else is discussing big ideas, it would be helpful for me
>> personally if autoconf just made a release with the latest bugfixes.
>
> Before I dive into the rest of this
> On 10 Nov 2022, at 21:10, Michael Orlitzky wrote:
>
> On Thu, 2022-11-10 at 12:16 -0500, Zack Weinberg wrote:
>>
>> Nobody has a whole lot of time to work on Autoconf at present, but I
>> would like to ask, anyway, what Autoconf could potentially do to make
>> this transition easier.
>
>
* Rich Felker:
> I've been writing/complaining about autoconf doing this wrong for
> decades, with the best writeup around 9 years ago at
> https://ewontfix.com/13/. Part of the reason is that this has bitten
> musl libc users over and over again due to configure finding symbols
> that were
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
On Thu, Nov 10, 2022 at 1:12 PM Jonathan Wakely via cfe-commits
wrote:
>
> On Thu, 10 Nov 2022 at 17:58, Jonathan Wakely wrote:
> >
> > On Thu, 10 Nov 2022 at 17:52, Nick Bowler wrote:
> > > It saddens me to see so much breakage happening in "modern C", a
> > > language that has (until now) a
On Thu, Nov 10, 2022 at 12:16 PM Zack Weinberg via cfe-commits
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
On Thu, 10 Nov 2022 at 17:58, Jonathan Wakely wrote:
>
> On Thu, 10 Nov 2022 at 17:52, Nick Bowler wrote:
> > It saddens me to see so much breakage happening in "modern C", a
> > language that has (until now) a long history of new language features
> > being carefully introduced to avoid these
* Zack Weinberg via Gcc:
> 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 several “legacy” C language
On Thu, Nov 10, 2022 at 12:16:20PM -0500, 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
On Thu, 10 Nov 2022 at 17:52, Nick Bowler wrote:
> It saddens me to see so much breakage happening in "modern C", a
> language that has (until now) a long history of new language features
> being carefully introduced to avoid these sort of problems.
The features were introduced in 1999. Compilers
On 2022-11-10, Zack Weinberg wrote:
> The biggest remaining (potential) problem, that I’m aware of, is that
> AC_CHECK_FUNC unconditionally declares the function we’re probing for
> as ‘char NAME (void)’, and asks the compiler to call it with no
> arguments, regardless of what its prototype
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 several “legacy” C language features by
default in a near-future
64 matches
Mail list logo
