[Top][All Lists]

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

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

From: Paul Eggert
Subject: Re: [PATCH] Port to 32-bit long + 64-bit time_t
Date: Sun, 2 Oct 2022 17:06:40 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0

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...).

reply via email to

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