Jacob Bachmeyer wrote:
> Perhaps this has already been addressed, but what prevents a 32-bit OS
> from nonetheless having a 64-bit time_t?
Nothing. That's the case in particular on
- Linux on arc, loong32, ork1, riscv32 and x86_64-x32,
- NetBSD 6.0 (2012) and later on x86 and sparc,
- OpenBSD 5.5
Samuel Thibault wrote:
> > This adds SIGSEGV_FAULT_STACKPOINTER for the hurd-amd64 case
> >
> > --- ./lib/sigsegv.c.original2023-05-05 10:45:54.673751100 +
> > +++ ./lib/sigsegv.c 2023-05-05 10:48:47.903577554 +
> > @@ -351,6 +351,17 @@
> > "old esp, if trapped from user". */
Oops, that patch has a bug in the rare case where the stack buffer isn't
large enough: it might access freed storage. Fixed by installing the
attached further patch.From f01d8792778b637f7464533ac019e42f58adb310 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Fri, 12 May 2023 12:23:49 -0700
Subj
On 2023-05-04 02:36, Bruno Haible wrote:
"Avoid arbitrary limits on the length or number of any data structure,
including file names, lines, files, and symbols, by allocating all data
structures dynamically."
Yes, and I installed into Gnulib the attached patch, which follows that
gu
Paul Eggert wrote:
> > 3) The hint
> >
> > Did you mean to build a 64-bit binary? (E.g.,
> > 'CC="gcc -m64"'.)
> >
> > should not occur on a 32-bit OS. It should only occur on bi-arch systems
> > (64-bit OS, 32-bit $CC).
>
> If we could come up with a reliable way to distinguish between th
Hi,
I just tried to use this function and gave up.
I appreciate that it is carefully written to cope with a wide variety of
situations, but at present it looks more like the innards of something else
(which indeed it appears to be, I see it in coreutils's mkdir!) rather than
a reusable function (
