2038 is closer than it seems

Posted May 22, 2014 3:03 UTC (Thu) by adler187 (guest, #80400)
Parent article: 2038 is closer than it seems

Sounds like they copied the solution for Large File Support, ie. _FILE_OFFSET_BITS switches between the old 32-bit filesystem interfaces and the 64-bit filesystem interfaces.

to post comments

2038 is closer than it seems

Posted May 22, 2014 4:20 UTC (Thu) by mezcalero (subscriber, #45103) [Link] (2 responses)

Uh oh. Claiming that TIME_BITS=64 could allow a smooth transition is really wrong. The type time_t is exposed in numerous library APIs. The TIME_BITS=64 thing suggests one could mix and match components compiled with different settings freely, but that is not the case: if you compile one lib with 64bit time_t then you have to do the same for all programs using that lib. And if you do that the you transitively have to recompile all other libs they are using too, and so on. Ultimately you have to recompile the full system that way... Unless of course every single library would do what glibc does and provide both 32bit and 64bit calls for everything. And that's just not going to happen.

The same story happened for large file support (LFS) where off_t got increased in size. Now, off_t is thankfully not that often exposed in APIs, and because people knew how awful the situation was many just avoided exposing it in APIs, but for time_t the situation is much worse.

Also, one particular gem: think of stat() which already exists in two flavours, with LFS and without. Now, this API would also have to be duplicated for 32bit time_t and 64bit time_t. So you get four flavours of this call: stat(), stat64(), stat_t64() and stat64_t64()! Ouch!

And even thinking of duplicating gettimeofday() when there's also clock_gettime(CLOCK_REALTIME) is just wrong...

Lennart

2038 is closer than it seems

Posted May 22, 2014 7:27 UTC (Thu) by niner (guest, #26151) [Link] (1 responses)

Since stat() without LFS support is only for compatability, I assume it would suffice to add a stat64_t64 (with hopefully a better name). But having three variants is bad enough.

2038 is closer than it seems

Posted May 22, 2014 9:48 UTC (Thu) by arnd (subscriber, #8866) [Link]

For the particular example, we have been talking about a replacement for stat that solves a number of other problems as well. See http://lwn.net/Articles/394298/ for instance.