On 1/8/06, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
On Jan 7, 2006, at 9:23 PM, Justin Haygood wrote:Try telling that to date_object.cpp. It does the Windows equivalent of dumping core anytime a negative date value is used or a new Date object is created.Sounds bad. Do you have any ideas how that could be fixed? I'll have a Windows laptop soon so I may be able to test things myself.Regards,MaciejOn 1/8/06, Maciej Stachowiak < [EMAIL PROTECTED]> wrote:On Jan 7, 2006, at 9:13 PM, Justin Haygood wrote:Either one is an issue.
Windows does do one thing better: it supports dates beyond the 2038 even in vanilla localtime/gmtime.. it uses 64-bit values since the epoch by default in CRT 8.Actually I'm not sure we'd use negative time values with the latest code. Is there a case where this comes up? I think dates are converted into a consistent narrow range currently.Regards,MaciejOn 1/8/06, Maciej Stachowiak < [EMAIL PROTECTED]> wrote:
On Jan 7, 2006, at 8:57 PM, Justin Haygood wrote:
> The only problem with localtime_r and gmtime_r, when implemented in
> any matter that uses the CRT (We target CRT 8.. its the most
> current and really the only viable CRT) is that they don't work
> with negative time values, returning a NULL pointer.
>
> Since KJS doesn't realize that a NULL pointer can be given to it,
> it crashes miserably once it attempts to use this pointer.
Are the _s variants safe for use with negative time values? How about
vanilla localtime()? It seems like this is an issue regardless.
Cheers,
Maciej
_______________________________________________ webkit-dev mailing list [email protected] http://www.opendarwin.org/mailman/listinfo/webkit-dev
