Tcl Source Code

To what extent does/should Tcl 9.0 assume/require/enforce 64-bit time_t?

Currently, when I build Tcl 9.0 on ia32 (32-bit x86) Linux, it uses 32-bit time_t, but the tests cmdAH-24.20.1 and cmdAH-24.20.2 fail (rather than skip as with 8.7; timestamp 3155760000 overflows to -1139207296). I can also reproduce the issue in [fa128568a597]. (Maybe the same would happen for 32-bit ARM.)

I read elsewhere that glibc 2.34 and Linux kernel 5.6 support 64-bit time_t on 32-bit systems by compiling with _FILE_OFFSET_BITS=64 and _TIME_BITS=64 defined, and that future glibc may even define these by default. I tried building Tcl 9.0 again with these defined, and confirmed that doing so avoids the overflow issues. This approach reportedly supersedes/conflicts with the approach of defining _LARGEFILE64_SOURCE, as proposed removed in the bug-02b58d5d04 branch. Would it be appropriate for Tcl/Tk to instead define _FILE_OFFSET_BITS=64 and _TIME_BITS=64 by default (possibly before package managers all begin separately trying to do so themselves)?

If a system has a 64-bit time_t, but those 2 testcases fail, we still want a bug-report!

[cc0fee411c13b2b5]. Thanks!

In that case, I would suggest leaving a message in cmdAH-24.20.1/cmdAH-24.20.2 about the expected failures, so as to avoid further duplicate bug reports or someone adding back the time64bit constraint.

In that case, we shouldn't _enforce_ time64_t, just encourage it, doing everything possible to enable it. If that's not possible, everything works except 2 test-case failures: that should be enough warning not to trust the system any more when the year approaches 2038. OK?

Many thanks!

Thanks. Unfortunately, the glibc and kernel version in Ubuntu 16.04 will not support this approach, so what you see is expected. Ubuntu 21.10 (the first release with glibc 2.34) is likely the earliest that will work.

config.log now attached to this ticket

Ubuntu-16.04.1

Jan, can I please take a look at config.log if possible? Which Ubuntu version is used?

Trying this branch on 32-bit Ubuntu:

....
checking for 64-bit time_t... no
checking if _TIME_BITS=64 enables 64-bit time_t... no
configure: error: no 64-bit time_t available

So, it's not right yet

Thanks for the patch. I committed it to its own [58faf80de7e28662|branch] in order to do some testing.

In the meantime I also did some thinking what way I would like to go. Your implementation exactly looks like that! Many thanks, I like it!

I don't think it's really necessary to officially drop support for systems with a 32-bit time_t. A few failing testcases (showing that time functions won't work as expected after 2038 any more) should be enough.

Also, I may also be underestimating how controversial it would be for Tcl 9.0 to require 64-bit time_t, as this would drop support (if they haven’t been dropped already) for certain less popular systems such as FreeBSD i386.

I think that Tcl 9.0 - indeed - should enforce 64-bit time_t. … So, if you want to provide a patch for your platform (best place would be in tcl.m4), yes please!

Thanks for the suggestion, I have zero experience with M4 but have cargo culted roughly how this could be done anyway:

• Hack SC_TCL_EARLY_FLAG() to accept a 4th optional argument for the value to define a C macro to (1 by default)
• Define _FILE_OFFSET_BITS=64 during SC_TCL_EARLY_FLAGS if that is needed to get 64-bit off_t
• Define _TIME_BITS=64 during SC_TCL_64BIT_FLAGS if that is needed to get 64-bit time_t
• Error out if 64-bit time_t is unavailable.

See https://github.com/tcltk/tcl/compare/main...chrstphrchvz:tcl:timet64 (currently based on main branch, but would eventually prefer to base it on bug-02b58d5d04).

I believe I misunderstood the purpose of the bug-02b58d5d04 branch, and that the proposal in this ticket would actually complement the work in it: _FILE_OFFSET_BITS=64 affects the functions exposed by _LARGEFILE_SOURCE, as an alternative to using functions exposed by _LARGEFILE64_SOURCE which that branch removes usage of. Can that branch please be updated from the current main branch?

> To what extent does/should Tcl 9.0 assume/require/enforce 64-bit time_t?

I think that Tcl 9.0 - indeed - should enforce 64-bit time_t. That used to be a problem in Windows (since older msvcrt libraries don't have 64-bit time functions), but that's solved now. So, if you want to provide a patch for your platform (best place would be in tcl.m4), yes please!