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