64bit time_t in Linux Kernel

neutrino-pl · 03-16-2015, 02:29 PM

I have compiled kernel 3.19.1 but still have a problem with time_t. Just simple program with cout << sizeof (time_t); gives size of 4 bytes, not 8 bytes as was my intention. Should I switch on a particular option during make menuconfig?

Pearlseattle · 03-16-2015, 05:30 PM

Weird.

My code (some garbage around):

Code:

#include <stdio.h>
#include <stdlib.h>
#include <iostream>
#include <string>

using namespace std;

int main(int argc, char **argv)
{
        cout << sizeof (time_t);
}

Compilation:
g++ test.cpp -o test

Result:
8

You're sure that you're using a 64bit OS?
What's the output of "uname -a"?

neutrino-pl · 03-17-2015, 12:01 PM

Yes, that is true. I have tested it with 32bit Linux and 32bit CPU.
Is it possible to patch the kernel and have long and time_t types with size of 8 bytes on 32bit CPU?
Maybe '64-bit kernel' option during make menuconfig should solve that issue?

smallpond · 03-17-2015, 01:21 PM

Why would changing the kernel affect a user-space program? Are you specifying -m32 or -m64?

273 · 03-17-2015, 01:35 PM

I'm probably typing out of turn as I'm out of my depth here but a memory of trying to learn C and a google makes me think that time_t will be defined in the C libraries you link to so is that clib[or whatever]?
Please ignore, and sorry, if I am obviously ignorant.

neutrino-pl · 03-17-2015, 01:51 PM

Quote:

Originally Posted by smallpond

Why would changing the kernel affect a user-space program? Are you specifying -m32 or -m64?

http://git.rocketboards.org/?p=linux...d0fd8a9f10e8aa

smallpond · 03-17-2015, 05:54 PM

Quote:

Originally Posted by neutrino-pl

http://git.rocketboards.org/?p=linux...d0fd8a9f10e8aa

What does code for a system-on-chip FPGA have to do with this discussion?

ljb643 · 03-17-2015, 07:55 PM

Quote:

Originally Posted by smallpond

Why would changing the kernel affect a user-space program? Are you specifying -m32 or -m64?

Not the kernel, but the architecture? My understanding is that on a 64 bit system, time_t is defined as 64 bits; on a 32 bit system it is 32 bits. That is how I read <bits/types.h> and <bits/typesizes.h>, but I could be wrong.

From another point of view, I've always read that the solution to the Unix/Linux "year 2037 problem" when the old time_t wraps around is the 64 bit architecture which has a bigger time_t.

Pearlseattle · 03-18-2015, 02:25 PM

Maybe there is a workaround, depending on what you want want to do / what the reason is for you to get time_t as 64bit or bigger.

neutrino-pl · 03-18-2015, 05:19 PM

I have decided to use boost:: posix_time:: ptime instead of time_t and related functions like mktime().

Pearlseattle · 03-18-2015, 05:44 PM

Thx - and I agree, most probably the best alternative.

neutrino-pl · 03-19-2015, 02:39 AM

Well, it is indeed a good alternative. Right now I have to make some software for x86 embedded platform which is of course 32bit architecture. It's only a little chance it will still run on 2038, but who knows... better to be prepared

mina86 · 03-19-2015, 08:46 AM

Kernel defines what time_t is, standard C library just obeys, because it has no other choice.

You cannot patch a kernel to change time_t to 64-bit on x86 because that would change the ABI of a time syscall and in turn all of your user-space. To make that work youd have to rebuild your whole system starting from C library. And of course hunt all the bugs in applications where author assumed sizeof(time_t) == sizeof(long) or something similar.

Using Boost (or anything else) does not solve the problem of system time wrapping around 2038 on 32-bit systems.

PS. This might be a better fit for Programming forum.

neutrino-pl · 03-19-2015, 12:35 PM

Boost does not affect the system date and time_t of course, but solves the y2038 problem in my piece of code. That's enough for me.
In case of system time maybe here's a little hope:
http://lwn.net/Articles/607741/