linux 64-bit time_t implementation?

Support and discussions for the x86/x64 Linux version of Pale Moon and specific Linux distribution questions related to the browser.

Moderator: trava90

Forum rules
If your question is about general use of the browser and not specific to Linux, then please use the General Support board.
Locked
Walter Dnes
Astronaut
Astronaut
Posts: 631
Joined: 2015-07-30, 20:29
Location: Vaughan, ON, Canada

linux 64-bit time_t implementation?

Post by Walter Dnes » 2020-02-16, 01:47

According to https://www.zdnet.com/google-amp/article/linux-is-ready-for-the-end-of-time/ 64-bit time_t should be available in the linux 5.6 kernel. The following applies to both 32-bit and 64-bit linux systems. A significant gotcha is...
All user space must be compiled with a 64-bit time_t, which will be supported in the coming musl-1.2 and glibc-2.32 releases, along with installed kernel headers from Linux-5.6 or higher.
Up till now linux applications (e.g. Pale Moon) have had to be built for 2 environments
* 32-bit X86 with 32-bit time_t
* 64-bit AMD64 with 32-bit time_t

soon we'll be looking at 2 additional environments
* 32-bit X86 with 64-bit time_t
* 64-bit AMD64 with 64-bit time_t

The article implies that 32 and 64 bit time_t are incompatible with each other. Switching entirely to 64-bit time_t would kill support for all current 32 and 64 bit linux. Not having 64-bit time_t would mean Pale Moon doesn't run on the newest linux kernels when they come out. Is it possible to have 32 and 64 bit time_t calls in their own ifdefs? They would need to be activated by something like "--enable-32bit-time" at build time.

Eventually, 32-bit time_t will disappear from linux, but for now, things could be "interesting".
There's a right way
There's a wrong way
And then there's my way

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 27794
Joined: 2011-08-28, 17:27
Location: Tranås, SE
Contact:

Re: linux 64-bit time_t implementation?

Post by Moonchild » 2020-02-16, 02:26

Considering the actual date where this is needed is 18 YEARS away, they should reconsider breaking everything and demanding that all Linux software developers double their workload.
How about instead of doing this, using those 18 years to come up with a compatible solution?
"There will be times when the position you advocate, no matter how well framed and supported, will not be accepted by the public simply because you are who you are." -- Merrill Rose
Image

Walter Dnes
Astronaut
Astronaut
Posts: 631
Joined: 2015-07-30, 20:29
Location: Vaughan, ON, Canada

Re: linux 64-bit time_t implementation?

Post by Walter Dnes » 2020-02-16, 20:16

Moonchild wrote:
2020-02-16, 02:26
Considering the actual date where this is needed is 18 YEARS away, they should reconsider breaking everything and demanding that all Linux software developers double their workload.
I think that the Y2K panic taught people a lesson about not putting off things to the last minute. As for "double the workload", it'll probably be a short transition thing. When software devs do get serious, applications, with 32-bit time_t will simply stop being available. I believe that ssl certificate expiry dates tend to be in the order of several months, not years. But RSA certificates are another story. According to https://techcommunity.microsoft.com/t5/ ... a-p/272758 a 4096-bit key can be valid for up 16 years into the future (i.e. 2036). Breaking that breaks ssh. Remember that the first kernel drop will probably require some debugging, so they'll be cutting things a bit close for comfort.
Moonchild wrote:
2020-02-16, 02:26
How about instead of doing this, using those 18 years to come up with a compatible solution?
Sorry, compatability is simply not possible, for the same reason IPV6 could not be compatible with IPV4. IPV4 uses a 32-bit address. 2^32 addresses, minus reserved ranges, cannot contain the number of addresses required by 7+ billion people and a host of IDIOT (Insecurely Designed Internet Of Things) devices.

Similarly, a signed 32-bit signed integer cannot store the count of seconds from January 1, 1970 to January 20, 2038. An ugly hack that changes the interpretation of 32-bit time_t would wreak just as much havoc on existing systems as switching over to 64-bit time_t. And ugly hacks tend to come back to bite you in the ass eventually. A really quick-n-dirty solution to Y2K on 2-digit-year systems was "windowing". The original code interpreted 00...99 as 1900...1999 internally. The code was modified to interpret 00...19 as 2000...2019 and 20...99 as 1920...1999. Along comes January 1st, 2020... oops... https://www.usatoday.com/story/tech/202 ... 419535002/ Lesson learned... do it right the first time.
There's a right way
There's a wrong way
And then there's my way

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 27794
Joined: 2011-08-28, 17:27
Location: Tranås, SE
Contact:

Re: linux 64-bit time_t implementation?

Post by Moonchild » 2020-02-16, 21:31

So why exactly are you bringing this up here anyway? Is there a specific issue that you know of in Pale Moon that needs to be addressed? I don't think we use unix time much if at all in critical areas.
"There will be times when the position you advocate, no matter how well framed and supported, will not be accepted by the public simply because you are who you are." -- Merrill Rose
Image

Walter Dnes
Astronaut
Astronaut
Posts: 631
Joined: 2015-07-30, 20:29
Location: Vaughan, ON, Canada

Re: linux 64-bit time_t implementation?

Post by Walter Dnes » 2020-02-16, 23:02

Two reasons for bringing this up now...

1) A request that if any 32-bit time_t code is present, please don't tear it out prematurely

2) A heads-up (for 29.X) in case Pale Moon doesn't work for people running 64-bit time_t. I don't think we would want to tell users of newest linux spins to use another browser when 64-bit time_t hits. The market share of 64-bit time_t machines will increase with time.

The perfect scenario would be if Pale Moon doesn't do direct time_t calls, and the same binary could run on
* an older linux (pre-5.6 kernel and pre-2.32 glibc) running 32-bit time_t
* and a 5.6 or later kernel, with 2.32 or later glibc, running 64-bit time_t
There's a right way
There's a wrong way
And then there's my way

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 27794
Joined: 2011-08-28, 17:27
Location: Tranås, SE
Contact:

Re: linux 64-bit time_t implementation?

Post by Moonchild » 2020-02-16, 23:25

I think the only use of time_t where it would actually matter come 2038 would be the js DateTime source, but even there we already use 64-bit ints to store the max unix time. Even so, any adjustments needed there are probably 10 minutes of work or less.

The whole point of using *_t variable types like size_t, time_t and other unspecified _t types, to begin with, is that they are bitness-agnostic (you can use the same type on different bit-width natives without causing trouble), so there shouldn't be an inherent problem at all if the bitness of time_t changes to 64. Where storage sizes of variables matter we already check the size of time_t's data structure and use that dynamically; if we didn't we would likely already have problems simply having 32-bit and 64-bit binaries ;)
And there won't be a problem storing the same 32-bit value in a 64-bit wide variable...
"There will be times when the position you advocate, no matter how well framed and supported, will not be accepted by the public simply because you are who you are." -- Merrill Rose
Image

Locked