bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [PATCH] Port to 32-bit long + 64-bit time_t


From: rsbecker
Subject: RE: [PATCH] Port to 32-bit long + 64-bit time_t
Date: Mon, 3 Oct 2022 12:12:22 -0400

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
>have another pair of eyes look at this finicky business once you've published 
>your
>mods.
>
>
>> Is there ever a system anywhere that can't represent any remotely
>> useful year value using an int (even if you add
>> 1900 to it :) )?
>
>My use case was if someone sets a file timestamp to something oddball and then
>'make' mishandles the result. This sort of thing happens more often than one
>would like.
>
>As it happens today I fixed a glitch in an oddball part of the GNU Emacs build
>process that uses "TZ=UTC0 touch -t 197001010000" to set file timestamps to 0 
>and
>thus fool 'make'. (This was not my idea! and doesn't GNU 'make' treat a zero 
>file
>timestamp specially? but I digress.) It's not a stretch to think of someone 
>using
>'touch' to set file timestamps in the far future, for a similar reason.
>
>For example, here's what happens on a filesystem that supports 64-bit
>timestamps:
>
>   $ TZ=UTC0 touch -d @67767976233532800 foo
>   $ TZ=UTC0 ls -l foo
>   -rw-rw-r-- 1 eggert faculty 0 Jan  1  2147483648 foo
>
>Here the year is 2**31, which works because tm_year is 2**31 - 1900 which fits 
>in
>32-bit int even though 2**31 does not fit. This works with GNU ls, which uses
>strftime which does things correctly. It won't work with GNU Make's C code that
>simply adds 1900 to tm_year.
>
>Come to think of it, if file_timestamp_sprintf simply used strftime instead of
>sprintf that would be more-straightforward fix (this is part of the "finicky 
>business"
>I was talking about earlier...).

At least you get bigger numbers with an unsigned time_t. On my platform, I get 
stuff like May 1954. 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.

-Randall




reply via email to

[Prev in Thread] Current Thread [Next in Thread]