test-fs-utimes-y2K38 fails on 32-bit platforms with 64-bit time_t

[awilfox]

Version

v18.12.1

Platform

Linux ember.foxkit.us 5.15.44-mc2-easy #1 SMP Wed Aug 17 20:37:04 UTC 2022 i686 GNU/Linux

Subsystem

fs

What steps will reproduce the bug?

1. make jstest on a 32-bit computer with 64-bit time_t.

How often does it reproduce? Is there a required condition?

Always reproducible on any 32-bit computer with 64-bit time_t. This includes Linux musl libc, and glibc when _TIME_BITS=64.

What is the expected behavior?

Passing tests.

What do you see instead?

=== release test-fs-utimes-y2K38 ===                                          
Path: parallel/test-fs-utimes-y2K38
node:assert:124
  throw new AssertionError(obj);
  ^

AssertionError [ERR_ASSERTION]: Expected values to be strictly equal:
+ actual - expected

+ -2147483648
- 2147483648
    at Object.<anonymous> (/usr/src/packages/user/node/src/node-v18.12.1/test/parallel/test-fs-utimes-y2K38.js:48:8)
    at Module._compile (node:internal/modules/cjs/loader:1159:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1213:10)
    at Module.load (node:internal/modules/cjs/loader:1037:32)
    at Module._load (node:internal/modules/cjs/loader:878:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
    at node:internal/main/run_main_module:23:47 {
  generatedMessage: true,
  code: 'ERR_ASSERTION',
  actual: -2147483648,
  expected: 2147483648,
  operator: 'strictEqual'
}

Node.js v18.12.1
Command: out/Release/node /usr/src/packages/user/node/src/node-v18.12.1/test/parallel/test-fs-utimes-y2K38.js

Additional information

This is passing on the 16 LTS branch. It seems like it may be fallout from #43714 but I'm not sure.

[bnoordhuis]

cc @LiviaMedeiros

Libuv is probably also partially - if not wholly - to blame for using long for uv_timespec_t.tv_sec.

[LiviaMedeiros]

Not sure if it can be fixed without changes in libuv or without breaking dates before 1970-01-01 again.
However, I'm curious if the issue affects only retrieving stats or also setting the mtime.
Does

node -e 'fs.writeFileSync("/tmp/issue45906","");fs.utimesSync("/tmp/issue45906",2**31,2**31);' && stat /tmp/issue45906

return 2038-01-19 03:14:08 as atime and mtime on such systems?

[zv-io]

@LiviaMedeiros that command returns:

  File: /tmp/issue45906
  Size: 0               Blocks: 0          IO Block: 4096   regular empty file
Device: 0,28    Inode: 18331       Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/ builder)   Gid: (  300/  abuild)
Access: 2038-01-19 03:14:08.000000000 +0000
Modify: 2038-01-19 03:14:08.000000000 +0000
Change: 2022-12-23 14:10:14.383418177 +0000
 Birth: -

[awilfox]

I have realized that this is actually passing on 32-bit Arm (ARMv7) and I couldn't figure out why, but I just did – it is because x86 defaults to signed and Arm defaults to unsigned, so the long in uv is already unsigned there.

I think for us (I'm trying to package Node 18 for a Linux distro) it makes sense to just change it to unsigned long since that is already what is happening on Arm; not sure if it makes sense for you to do this upstream.

[bnoordhuis]

@awilfox long is always signed. You're thinking of char maybe?

(I figured it might be a time_t thing but that's always signed too, it seems.)