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

[Paul Eggert]

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