System call conversion for year 2038 [LWN.net]

System call conversion for year 2038

Posted May 13, 2015 3:10 UTC (Wed) by eternaleye (guest, #67051)
In reply to: System call conversion for year 2038 by flussence
Parent article: System call conversion for year 2038

Well, the 12-byte struct is what everyone's been working with on 64-bit for quite a while now as I understand it - 64-bit seconds, 32-bit nanoseconds (or microseconds, for the struct timeval antiques). On 32-bit it might even be _less_ painful, as on some 32-bit architectures (x86?) u64 has 4-byte alignment IIRC, rather than 8-byte.

to post comments

System call conversion for year 2038

Posted May 13, 2015 17:56 UTC (Wed) by joib (subscriber, #8541) [Link] (3 responses)

Struct timespec is specced in posix to have a time_t value for seconds since the epoch, and a long value for fractional nanoseconds. Both are 64 bits on 64-bit Linux targets.

System call conversion for year 2038

Posted May 13, 2015 20:37 UTC (Wed) by eternaleye (guest, #67051) [Link] (2 responses)

Oh, ick. 34 bits total of wastage? Sure, struct alignment would mean the same wastage in arrays, but still...

This is really reinforcing my preference for Rust's [ui]{64,32,16,8} integer types over C's (unsigned) {long long,long,int,short,char} fuzzily-sized ones :/

(and Rust then has usize, defined as "capable of holding a pointer", for the cases where that's relevant)

System call conversion for year 2038

Posted May 13, 2015 21:08 UTC (Wed) by rleigh (guest, #14622) [Link] (1 responses)

Are the Rust types not exactly the same as the long established C99 <stdint.h> or C++11 <cstdint>? I haven't used the "fuzzy" types much in over a decade!

System call conversion for year 2038

Posted May 13, 2015 23:01 UTC (Wed) by eternaleye (guest, #67051) [Link]

They are exactly that - but when POSIX defines things in terms of the fuzzy types, even the sensible people who use stdint can't escape.

(of course, for FFI there's libc::c_int and so on, but that's just it: for FFI.)