Re: On time64 and Large File Support

2022-11-14 Thread Sam James
> On 12 Nov 2022, at 21:31, Paul Eggert wrote: > > On 2022-11-12 12:23, Wookey wrote: >> we can't just have everyone who enabled LFS sometime in the >> last 20 years suddenly being forced into the time_t change (can we?) > > We've done it in the past. > > AC_SYS_LARGEFILE originally was in

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

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

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

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

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

2022-11-14 Thread Florian Weimer
* 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

Re: On time64 and Large File Support

2022-11-14 Thread Florian Weimer
* Arsen Arsenović: > Evening, > > Adam Sampson writes: >> If the consensus on this does come down to the definition of new >> architecture triplets, are there any other changes that should (or >> could) be made at the same time, beyond time64 and LFS? > > Forwarding a suggestion from Arfrever:

Re: On time64 and Large File Support

2022-11-14 Thread Adam Sampson
Florian Weimer via Libc-alpha writes: > We should define new target triplets for this if it's really required. If the consensus on this does come down to the definition of new architecture triplets, are there any other changes that should (or could) be made at the same time, beyond time64 and

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

2022-11-14 Thread 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 about how it diagnoses invalid

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

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

Re: On time64 and Large File Support

2022-11-14 Thread Arsen Arsenović
Evening, Adam Sampson writes: > If the consensus on this does come down to the definition of new > architecture triplets, are there any other changes that should (or > could) be made at the same time, beyond time64 and LFS? Forwarding a suggestion from Arfrever: > Please consider making

Re: On time64 and Large File Support

2022-11-14 Thread Florian Weimer
* Adam Sampson via Libc-alpha: > Florian Weimer via Libc-alpha writes: > >> We should define new target triplets for this if it's really required. > > If the consensus on this does come down to the definition of new > architecture triplets, are there any other changes that should (or > could) be