Messages in this thread | | | From | "David Schwartz" <> | Subject | RE: time_t size: The year 2038 bug? | Date | Wed, 5 Jan 2000 14:40:27 -0800 |
| |
> > No it is not. The argument used in the late seventies / > > early eighties was > > that nobody would be using the same application code. Most of > > us are writing > > application code now that makes no such date-related assumptions. A > > recompile will fix them.
> are you really sure that application programmers allocate space for dates > based on sizeof(date var) and do not assume that that is 32 bits?
Application programmers can allocate space or not, that's their decision. Well-written application code either uses its own date classes or uses date classes that are known to be safe for the range of dates the application is intended to handle. If we're talking about fixing application code, why are we doing it on the linux-kernel list?
> this is like the statement that was made last year on a firewall list that > anyone who remembered the leap year calculation was something other then > y/4 would remember the entire formula, this was discredited in the very > next post by someone who agreed that the formula was y/4 unless y/100 > (forgetting except y/400)
I don't understand the applicability of that analogy.
> I would lay serious money down that a lot of stuff that stores dates in > binary files only allocate 4 bytes for it without checking it's size.
Then that stuff is broken and needs to be fixed. But that's not a library issue and it's not a kernel issue. It's a "that stuff is broken" issue.
> (and yes I realize that this bet cannot really be settled until the 2038 > "crisis" hits)
True. But if I understand correctly the argument I'm responding to, it goes kind of like this:
"We have to make time_t Y2.038K-compliant long before 2038, now if possible, otherwise there will be no time left to fix application code. The sooner we fix time_t, the sooner we will start writing Y2.038K-compliant applications."
And my answer to that is that the size of a time_t has no bearing on properly-written application code. 'time_t' is an opaque type, and the only thing that is safe and legal to do with it is to pass it to and from library functions that take or give a 'time_t'.
People who write bad code will write bad code no matter how large a time_t is or isn't, and then code will break. Even if you make a time_t 64-bits, the people who cast it to an 'int' or write it into a 4-byte database slot will still be screwed on 32-bit machines.
The code I write today is Y2.038K-compliant. Long before 2038, there will be Y2.038K-compliant libraries to link it to and operating systems to run it on. My code will not break.
DS
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |