> > 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/
This archive was generated by hypermail 2b29 : Fri Jan 07 2000 - 21:00:04 EST