-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
64 bit time_t #17393
Comments
This brings us back in line with upstream musl. The change to 32-bit was only recently made in #16966. The reason we made this change was made was because we had certain C library calls that were implemented in JS that returned `time_t`. Since returning 64-bit values from JS functions is not always easy (we don't always have WASM_BIGINT available) that simplest solution was to define `time_t` to 32-bit which doesn't have issues at the JS boundary. However, in the intervening time many of the `time_t`-returning function have been moved into native code (See #16606 and #16439) with only two remaining: _mktime_js and _timegm_js. So this change redefines just those two functions to return `int` while keeping `time_t` itself as 64-bit. Fixes: #17393
This brings us back in line with upstream musl. The change to 32-bit was only recently made in #16966. The reason we made this change was made was because we had certain C library calls that were implemented in JS that returned `time_t`. Since returning 64-bit values from JS functions is not always easy (we don't always have WASM_BIGINT available) that simplest solution was to define `time_t` to 32-bit which doesn't have issues at the JS boundary. However, in the intervening time many of the `time_t`-returning function have been moved into native code (See #16606 and #16439) with only two remaining: _mktime_js and _timegm_js. So this change redefines just those two functions to return `int` while keeping `time_t` itself as 64-bit. Fixes: #17393
This brings us back in line with upstream musl. The change to 32-bit was only recently made in #16966. The reason we made this change was made was because we had certain C library calls that were implemented in JS that returned `time_t`. Since returning 64-bit values from JS functions is not always easy (we don't always have WASM_BIGINT available) that simplest solution was to define `time_t` to 32-bit which doesn't have issues at the JS boundary. However, in the intervening time many of the `time_t`-returning function have been moved into native code (See #16606 and #16439) with only two remaining: _mktime_js and _timegm_js. So this change redefines just those two functions to return `int` while keeping `time_t` itself as 64-bit. Fixes: #17393
This brings us back in line with upstream musl. The change to 32-bit was only recently made in #16966. The reason we made this change was made was because we had certain C library calls that were implemented in JS that returned `time_t`. Since returning 64-bit values from JS functions is not always easy (we don't always have WASM_BIGINT available) that simplest solution was to define `time_t` to 32-bit which doesn't have issues at the JS boundary. However, in the intervening time many of the `time_t`-returning function have been moved into native code (See #16606 and #16439) with only two remaining: _mktime_js and _timegm_js. So this change redefines just those two functions to return `int` while keeping `time_t` itself as 64-bit. Fixes: #17393
This brings us back in line with upstream musl. The change to 32-bit was only recently made in #16966. The reason we made this change was made was because we had certain C library calls that were implemented in JS that returned `time_t`. Since returning 64-bit values from JS functions is not always easy (we don't always have WASM_BIGINT available) that simplest solution was to define `time_t` to 32-bit which doesn't have issues at the JS boundary. However, in the intervening time many of the `time_t`-returning function have been moved into native code (See #16606 and #16439) with only two remaining: _mktime_js and _timegm_js. So this change redefines just those two functions to return `int` while keeping `time_t` itself as 64-bit. Fixes: #17393
I believe that the change broke some
|
Ha, that's ironic/unfortunate given that its was python folks who wanted this changed. Any ideas why it would be failing? |
Not yet, but I have a gut feeling that the utimensat syscall code should be changed to use bigint and 64bit ints. emscripten/src/library_syscall.js Lines 957 to 978 in 8c047b1
|
timespec struct definition depends on size of
|
Hmm.. it looks like the JS filesystem layer assumes timestamps are JS numbers, so we will not be able fully represent i64 times. Do you know if its reasonable for the value passed to If not then I think I might just revert this change since 32-bit time_t is more compatible with the JS layer (which represents time as JS number (double) number of seconds): https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/getTime |
Hmm.. looks like it may be ok to truncate: https://www.qnx.com/developers/docs/7.1/#com.qnx.doc.neutrino.lib_ref/topic/u/utimensat.html: "The time that's actually recorded depends on the resolution in the filesystem's data structures. For example, no matter what you put in the tv_nsec field, the time that a FAT filesystem records uses a 2-second granularity. The recorded time is the greatest value supported by the filesystem that isn't greater than the specified time." |
Still, I'm not sure it work the extra cost in code complexity and output side to have to deal with i64 here rather than i32. |
Playing around with linux is looks like its currently capping |
Yeah, a cap at 2^53-1 looks fine to me, too! 👍 |
Hopefully #17459 will fix you failure |
I have created a GH repo with daily GHA to run smoke tests of EMSDK tip-of-tree with CPython 3.11 and main branch, https://github.com/tiran/cpython-wasm-test/actions |
Thanks! The PR fixed most broken tests of CPython's test suite. The functions https://github.com/tiran/cpython-wasm-test/runs/7403750856 |
Fixed in #17471 . The PR also adds some tests for edge cases. |
Good news! CPython's test suite is passing again with Emscripten tot-upstream. |
This brings us back in line with upstream musl. The change to 32-bit was only recently made in emscripten-core#16966. The reason we made this change was made was because we had certain C library calls that were implemented in JS that returned `time_t`. Since returning 64-bit values from JS functions is not always easy (we don't always have WASM_BIGINT available) that simplest solution was to define `time_t` to 32-bit which doesn't have issues at the JS boundary. However, in the intervening time many of the `time_t`-returning function have been moved into native code (See emscripten-core#16606 and emscripten-core#16439) with only two remaining: _mktime_js and _timegm_js. So this change redefines just those two functions to return `int` while keeping `time_t` itself as 64-bit. Fixes: emscripten-core#17393
As discussed in pyodide/pyodide#2841, 2038 is only 16 years from now so it would be great to be able to represent dates further into the future as unix timestamps. In interest of this, we would like to be able to opt into a 64 bit time_t (or have it as the default).
The text was updated successfully, but these errors were encountered: