Florian Weimer wrote:
> 64-bit file offsets enabled real use cases.
Year 2038 is also a real use-case. It is not so rare that machines are
being used for 15 years. (I still occasionally use a 14-years old
computer, and had a washing machine that lasted 25 years.)
Year 2038 is less than 17 years a
Hi Paul,
> There is a way to build with 32-bit time_t even in Gnulib-using apps,
> so distros wanting to stick with 32-bit time_t can build Gnulib-using
> apps with the appropriate flags so that they're still living in the
> 32-bit time_t world for now.
What are these appropriate flags?
I'd
On 7/5/21 7:32 AM, Florian Weimer wrote:
I assume GNU clisp (at least in a full build) need to link to some
system libraries which are not dual ABI (and probably never will be).
If gnulib forces the use of time64 mode, then it creates a push towards
time64 mode in those libraries, too.
Only in
* Bruno Haible:
> Hi Florian,
>
>> > In glibc 2.34 on Linux kernels where time_t is traditionally 32-bit,
>> > defining _FILE_OFFSET_BITS=64 and _TIME_BITS=64 makes time_t 64-bit.
>> > Apps must define both macros. Gnulib applications that use either
>> > the largefile or the year2038 modules wil
On Tue, Jun 29, 2021 at 11:51:13AM +0300, Egor Ignatov wrote:
> Well, then I have a few questions about matching and capturing
> groups.
>
> 1. "ab" -> "^(a*)*(.)"
> So, from your test case I can assume that:
> regs[0] = (0, 2]
> regs[1] = (0, 1]
> regs[2] = (1, 2]
>
> But if we add backref at th
