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

2022-11-15 Thread Ben Boeckel
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,

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

2022-11-15 Thread Bob Friesenhahn
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,

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

2022-11-15 Thread Paul Eggert
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

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

2022-11-15 Thread Aaron Ballman
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

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

2022-11-15 Thread Aaron Ballman
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

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

2022-11-15 Thread Paul Eggert
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

Re: On time64 and Large File Support

2022-11-15 Thread Zack Weinberg
On Tue, Nov 15, 2022, at 2:02 PM, Nick Bowler wrote: > But neither suggestion makes any difference. Timestamps seem OK; it > appears that make is deciding to aclocal.m4 (and then configure) because > of prerequisites that do not exist outright: > > % make -d > [...] >Considering

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

2022-11-15 Thread Jonathan Wakely
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

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

2022-11-15 Thread Paul Eggert
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

Re: On time64 and Large File Support

2022-11-15 Thread Nick Bowler
On 2022-11-15, Zack Weinberg wrote: > On Tue, Nov 15, 2022, at 12:49 PM, Nick Bowler wrote: >> On 2022-11-13, Zack Weinberg wrote: >>> I have not pushed this, and have only tested it lightly on a current >>> Linux. >>> It needs testing on weird old systems, particularly old AIX, HP-UX, >>>

Re: On time64 and Large File Support

2022-11-15 Thread Zack Weinberg
On Tue, Nov 15, 2022, at 12:49 PM, Nick Bowler wrote: > On 2022-11-13, Zack Weinberg wrote: >> I have not pushed this, and have only tested it lightly on a current Linux. >> It needs testing on weird old systems, particularly old AIX, HP-UX, MinGW. > > I'd be happy to give it a go on my weird old

Re: On time64 and Large File Support

2022-11-15 Thread Nick Bowler
[dropping non-autoconf lists from Cc] On 2022-11-13, Zack Weinberg wrote: > I have not pushed this, and have only tested it lightly on a current Linux. > It needs testing on weird old systems, particularly old AIX, HP-UX, MinGW. I'd be happy to give it a go on my weird old systems ... > > I

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

2022-11-15 Thread Jonathan Wakely
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

Re: On time64 and Large File Support

2022-11-15 Thread Sam James
> On 13 Nov 2022, at 05:11, Zack Weinberg wrote: > > On Sat, Nov 12, 2022, at 4:33 PM, Zack Weinberg wrote: >> On Sat, Nov 12, 2022, at 4:31 PM, Paul Eggert wrote: >>> Because of the concerns raised in this thread it's become clear that >>> what's in Autoconf now is too drastic, and I've

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

2022-11-15 Thread Sam James
> 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

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

2022-11-15 Thread Zack Weinberg
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

Re: On time64 and Large File Support

2022-11-15 Thread Arsen Arsenović
Morning, Florian Weimer writes: > Uhm, this seems to be something affecting 64-bit targets, not 32-bit > targets, after the POSIX fix went in? We have a few more such quirks. > (I understood the question to be about cleanup opportunities for 32-bit > architectures.) Hmm, yes, not sure what he