On 10/3/22 12:56, Paul Eggert wrote:
In looking through old dev histories it appears Paul pushes changes
every now and then, so I'll wait until he's pushed his next batch of
changes, which will presumably include some timestamp-related fixes,
before looking into this again.
Thanks, that merge
On Tue, 2022-10-04 at 09:06 +0300, Eli Zaretskii wrote:
> > From: Paul Smith
> > Cc: bug-make@gnu.org
> > Date: Mon, 03 Oct 2022 16:14:01 -0400
> >
> > I needed another set of changes, since intmax_t is a new type and
> > is not available on Windows so we needed to add it to configure.ac
> > etc.
> From: Paul Smith
> Cc: bug-make@gnu.org
> Date: Mon, 03 Oct 2022 16:14:01 -0400
>
> I needed another set of changes, since intmax_t is a new type and is
> not available on Windows so we needed to add it to configure.ac etc.
By "not available on Windows" you mean in MSVC, right? Because MinGW
On Sun, 2022-10-02 at 17:06 -0700, Paul Eggert wrote:
> On 10/2/22 14:09, Paul Smith wrote:
>
> > I applied these changes but made a few mods:
>
> Thanks. I assume you'll push this to savannah at some point?
Pushed now.
I needed another set of changes, since intmax_t is a new type and is
not av
On 10/3/22 09:12, rsbec...@nexbridge.com wrote:
This happens in AR and TAR also, which appear to be limited to 32-bit time_t on
some platforms. It's a struggle but we have some time to deal with it.
Yes, I've been part of an ongoing effort to make GNU apps Y2038-safe,
even on 32-bit platforms
On October 3, 2022 3:56 PM, Paul Eggert wrote:
>On 10/3/22 09:12, rsbec...@nexbridge.com wrote:
>> This happens in AR and TAR also, which appear to be limited to 32-bit time_t
>> on
>some platforms. It's a struggle but we have some time to deal with it.
>
>Yes, I've been part of an ongoing effort
On 10/2/22 14:23, Paul Smith wrote:
I would be happy to use it, if using it didn't import a ton of other
things that require POSIX tools AND an already-working make program.
Oh, right, sorry, I was confusing inttypes.h (which takes some
configuring) with intprops.h (which doesn't).
On 10/2/
On October 2, 2022 8:07 PM Paul Eggert wrote:
>On 10/2/22 14:09, Paul Smith wrote:
>
>> I applied these changes but made a few mods:
>
>Thanks. I assume you'll push this to savannah at some point? I had been working
>on merging with your more-recent changes to GNU Make, and it wouldn't hurt to
>hav
> From: Paul Smith
> Cc: bug-make@gnu.org
> Date: Sun, 02 Oct 2022 17:23:46 -0400
>
> On Thu, 2022-09-22 at 11:00 -0700, Paul Eggert wrote:
> > (This would not be needed if 'make' used Gnulib's inttypes module.)
>
> I would be happy to use it, if using it didn't import a ton of other
> things th
On 10/2/22 14:09, Paul Smith wrote:
I applied these changes but made a few mods:
Thanks. I assume you'll push this to savannah at some point? I had been
working on merging with your more-recent changes to GNU Make, and it
wouldn't hurt to have another pair of eyes look at this finicky busine
On October 2, 2022 6:13 PM, Paul Smith wrote:
>On Sun, 2022-10-02 at 17:48 -0400, rsbec...@nexbridge.com wrote:
>> > I understand that this type of reuse makes things easier for the
>> > gnulib folks, but for GNU make I'm not ready to drop support for
>> > platforms that are not POSIX enough to run
On Sun, 2022-10-02 at 17:48 -0400, rsbec...@nexbridge.com wrote:
> > I understand that this type of reuse makes things easier for the
> > gnulib folks, but for GNU make I'm not ready to drop support for
> > platforms that are not POSIX enough to run configure, and that
> > don't already have "make"
On October 2, 2022 5:24 PM, Paul Smith wrote:
>On Thu, 2022-09-22 at 11:00 -0700, Paul Eggert wrote:
>> (This would not be needed if 'make' used Gnulib's inttypes module.)
>
>I would be happy to use it, if using it didn't import a ton of other things
>that
>require POSIX tools AND an already-worki
On Thu, 2022-09-22 at 11:00 -0700, Paul Eggert wrote:
> (This would not be needed if 'make' used Gnulib's inttypes module.)
I would be happy to use it, if using it didn't import a ton of other
things that require POSIX tools AND an already-working make program.
I understand that this type of reus
On Thu, 2022-09-22 at 11:00 -0700, Paul Eggert wrote:
> On 9/21/22 23:49, Eli Zaretskii wrote:
> > This will cause problems in the native MS-Windows builds, where
> > printf in the system C runtime doesn't support %lld and %llu.
>
> Thanks for the review. Revised patch attached. It also addresses
> Date: Thu, 22 Sep 2022 11:00:52 -0700
> Cc: rsbec...@nexbridge.com, bug-make@gnu.org
> From: Paul Eggert
>
> On 9/21/22 23:49, Eli Zaretskii wrote:
> > This will cause problems in the native MS-Windows builds, where printf
> > in the system C runtime doesn't support %lld and %llu.
>
> Thanks f
00 2001
From: Paul Eggert
Date: Tue, 20 Sep 2022 14:18:00 -0700
Subject: [PATCH] Port to 32-bit long + 64-bit time_t
Don't assume that time_t fits in long, as some hosts (e.g.,
glibc x86 -D_TIME_BITS=64) have 32-bit long and 64-bit time_t.
* bootstrap.conf (gnulib_modules): Add largefile, to
> Date: Wed, 21 Sep 2022 17:58:20 -0700
> Cc: bug-make@gnu.org
> From: Paul Eggert
>
> On 9/20/22 18:48, rsbec...@nexbridge.com wrote:
> > I am sorry to say that the %j prefix is not safe or portable. There are
> > major production platforms where this is not supported. I work on one of
> > them.
> From:
> Cc:
> Date: Wed, 21 Sep 2022 21:01:58 -0400
>
> On September 21, 2022 8:58 PM, Paul Eggert wrote:
> >On 9/20/22 18:48, rsbec...@nexbridge.com wrote:
> >> I am sorry to say that the %j prefix is not safe or portable. There
> >> are major production platforms where this is not supported.
On September 21, 2022 8:58 PM, Paul Eggert wrote:
>On 9/20/22 18:48, rsbec...@nexbridge.com wrote:
>> I am sorry to say that the %j prefix is not safe or portable. There
>> are major production platforms where this is not supported. I work on
>> one of them.
>
>Which platform and version? I'd like
17 00:00:00 2001
From: Paul Eggert
Date: Tue, 20 Sep 2022 14:18:00 -0700
Subject: [PATCH] Port to 32-bit long + 64-bit time_t
Don't assume that time_t fits in long, as some hosts (e.g.,
glibc x86 -D_TIME_BITS=64) have 32-bit long and 64-bit time_t.
This fix uses C99 sprintf/scanf %jd and %ju
On September 20, 2022 5:22 PM Paul Eggert wrote:
>Don't assume that time_t fits in long, as some hosts (e.g., glibc x86 -
>D_TIME_BITS=64) have 32-bit long and 64-bit time_t.
>This fix uses C99 sprintf/scanf %jd and %ju, which is safe to assume
nowadays.
I am sorry to say that the %j prefix is not
Don't assume that time_t fits in long, as some hosts (e.g.,
glibc x86 -D_TIME_BITS=64) have 32-bit long and 64-bit time_t.
This fix uses C99 sprintf/scanf %jd and %ju, which is
safe to assume nowadays.
* bootstrap.conf (gnulib_modules): Add largefile, to support
files with timestamps after Y2038 on
23 matches
Mail list logo
