6 Jan
2021
6 Jan
'21
6:20 p.m.
On 6 Jan 2021 12:08 -0500, from henry.r.bent(a)gmail.com (Henry Bent):
I haven't dug particularly deeply, but unless I am missing something,
Debian Buster's 4.19 kernel seems to map `time_t` to plain `long`
regardless of architecture. I don't have an i386 architecture system
handy, but wouldn't that make it 32 bits wide on i386 & Co?
linux/time.h:
struct timespec {
__kernel_time_t tv_sec; /* seconds */
long tv_nsec; /* nanoseconds */
};
asm-generic/posix_types.h:
#ifndef __kernel_long_t
typedef long __kernel_long_t;
typedef unsigned long __kernel_ulong_t;
#endif
/* ... */
typedef __kernel_long_t __kernel_time_t;
Both from Debian's linux-libc-dev package, version 4.19.160-2, amd64
architecture.
If that's right, then I'd definitely expect anything 2.x and 3.x to be
unsafe, and 4.x to at best be suspect; so Dario's mention of 5.6
doesn't sound unreasonable as a first guess.
We've got maybe fifteen years before this starts to become a real
issue. Time to start working on those upgrade plans...
--
Michael Kjörling • https://michael.kjorling.se • michael(a)kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”
On recent
Linux/i386 kernels it's actually 64 bits. In practice, only
users who are stuck with old i386 Linux versions will have a problem.
Do you happen to know what the cutoff is? Are 2.6 kernels (still very
common) safe? 3.x? 4.x?