> On 12 Nov 2022, at 02:20, Zack Weinberg via Libc-alpha
> wrote:
>
> Sam James writes:
>>> On 11 Nov 2022, at 09:19, Florian Weimer wrote:
>>> We need to support legacy binaries on i386. Few libraries are
>>> explicitly dual-ABI. Whether it's safe to switch libraries above glibc
>>> to LF
Sam James writes:
>> On 11 Nov 2022, at 09:19, Florian Weimer wrote:
>> We need to support legacy binaries on i386. Few libraries are
>> explicitly dual-ABI. Whether it's safe to switch libraries above glibc
>> to LFS or time64 needs to be evaluated on a per-library basis. For most
>> distribu
On 2022-11-11 03:38, Florian Weimer wrote:
But that said, these binaries are broken anyway in 2038?
No, I expect users to run them in time-shifted VMs or containers.
That's reasonable for systems where accurate timestamps are not
important and where time_t width mismatches would just get in t
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
* Sam James:
>> On 11 Nov 2022, at 09:19, Florian Weimer wrote:
>>
>> * Sam James:
>>
>>> In Gentoo, we've been planning out what we should do for time64 on
>>> glibc [0] and concluded that we need some support in glibc for a newer
>>> option. I'll outline why below.
>>>
>>> Proposal: glibc ga
> On 11 Nov 2022, at 09:19, Florian Weimer wrote:
>
> * Sam James:
>
>> In Gentoo, we've been planning out what we should do for time64 on
>> glibc [0] and concluded that we need some support in glibc for a newer
>> option. I'll outline why below.
>>
>> Proposal: glibc gains two new build-tim
> 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
Hi Andreas,
> Historically, I've suggested taking care of these kinds of things in the
> richacl project, but that effort has been shot down upstream, and that
> project has been dead for a long time.
I think I have complete picture now. I also think that eventually I can
eventually fix gnulib
