I still have this todo item: On 12/30/2016 11:28 AM, darken wrote: > I've seen a value of "18446744072363093454" for stat %Z (seconds since > epoch), for some files on a users device (Android 6.01).
To which Elliot replied with: On 12/30/2016 01:39 PM, enh wrote: > time_t on 32-bit Android is 32 bits. > > that particular value looks like a sign-extension of 0xAFBEADCE, which > is still some time in 2063. (so i'd assume this device's clock is set > wrong, and i'd assume -- since this is presumably a 32-bit device with > a signed 32-bit time_t -- that that's going to be causing other > problems too.) Then I said: > Or if it's signed, that's -1346458162 which would be... sometime in the > 1930's? hmmm... "./date -D %s -d -1346458162" is failing under glibc, > and failing _differently_ under musl. (Wheee.) At which point I got distracted going off on a tangent instead of just using "touch -d". Years ago Linus ruled ex cathedra that time_t is gonna stay signed on Linux (because otherwise you can't represent times before Jan 1 1970, which a lot of people's birthdays still are): https://lkml.org/lkml/2011/8/31/246 Which means a 32 bit time_t has the year 2038 problem (and x32 needs a 64 bit time_t to stay relevant). The problem here _isn't_ about casting time_t to unsigned, because it isn't an unsigned value. (And unsigned 64 bit value still couldn't represent times before 1970: it has to _remain_ signed after being promoted to 64 bits or it's broken.) That's why I didn't apply Elliott's patch with the sizeof() and typecast staircase: I don't see how it can be the proper fix to the reported problem: > with 64-bit toybox: > > angler:/ # date 060200002064 That date is past 2038... > Mon Jun 2 00:00:00 GMT 2064 > angler:/ # rm /data/local/tmp/empty > angler:/ # touch /data/local/tmp/empty > angler:/ # ls -l /data/local/tmp/empty > -rw-rw-rw- 1 root root 0 2064-06-02 00:00 /data/local/tmp/empty > angler:/ # stat /data/local/tmp/empty > File: `/data/local/tmp/empty' > Size: 0 Blocks: 0 IO Blocks: 512 regular empty file > Device: fd00h/64768d Inode: 3014659 Links: 1 > Access: (666/-rw-rw-rw-) Uid: ( 0/ root) Gid: ( 0/ root) > Access: 2064-06-02 00:00:11.746667836 > Modify: 2064-06-02 00:00:11.746667836 > Change: 2064-06-02 00:00:11.746667836 > angler:/ # stat -c "%z %Z" /data/local/tmp/empty > 2064-06-02 00:00:11.746667836 2979590411 > angler:/ # ^D A 64 bit platform can represent that but a 32 bit one can't, because it's past y2038. > then with 32-bit toybox: > > angler:/ # ls -l /data/local/tmp/empty > -rw-rw-rw- 1 root root 0 1928-04-26 17:31 /data/local/tmp/empty Because time_t is a 32 bit signed value there, so that bit pattern represents a negative number. > angler:/ # stat /data/local/tmp/empty > File: `/data/local/tmp/empty' > Size: 0 Blocks: 0 IO Blocks: 512 regular empty file > Device: fd00h/64768d Inode: 3014659 Links: 1 > Access: (666/-rw-rw-rw-) Uid: ( 0/ root) Gid: ( 0/ root) > Access: 1928-04-26 17:31:55.746667836 > Modify: 1928-04-26 17:31:55.746667836 > Change: 1928-04-26 17:31:55.746667836 > angler:/ # stat -c "%z %Z" /data/local/tmp/empty > 1928-04-26 17:31:55.746667836 18446744072394174731 Why is "stat" showing the same data as "ls" a bad thing here? Your patch to stat makes it diverge from ls? On a local i686-musl build: / # touch -d 1928-04-26T00:00:00 walrus / # ls -l walrus -rw-r--r-- 1 root root 0 1928-04-26 00:00 walrus / # stat walrus File: `walrus' Size: 0 Blocks: 0 IO Blocks: 512 regular empty file Device: 801h/2049d Inode: 14574425 Links: 1 Access: (644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 1928-04-26 00:00:00.000000000 Modify: 1928-04-26 00:00:00.000000000 Change: 2017-02-08 20:58:37.009291677 / # > two patches attached. one avoids sign extension for all calls to > `out`, fixing %Z for systems with a signed 32-bit time_t. What does this patch fix? Rob _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net