[webkit-dev] KJS Date Object : thread safetyness / portability concerns

[Justin Haygood]

(Sorry for the subject change -- updating to make it more accurate --
threaded mail readers should still keep it in the thread)

My proposal:

Based on
http://www.tondering.dk/claus/cal/node3.html#SECTION00370000000000000000,
and some programming knowledge, how about:


   - For Windows, check the value of clock. If its 0 or less (it
   sometimes messes up with 0, sometimes it doesn't...), keep adding 28 years
   in seconds until its positive (no need to check for above 2038.. Windows
   uses 64-bit values for time_t if using CRT 8 (aka Visual Studio 2005's CRT)
   to increase portability between Win32 & Win64.
   - Remember the offset in years
   - Then, submit that time to the system local/gmtime function
   (whichever one we choose, aren't we going with the _s versions?)
   - Change the returned year using our remembered offset
   - Voila, immediate portability.

We might want to do this globally instead of just for one platform. We might
also do this for years above 2038 as well if time_t is 32-bit instead of
64-bit on a given platform.

sizeof(time_t) using MSVC 8 compiler and MSVCRT 8 C library: 8
sizeof(time_t) using MinGW GCC 3.4.2 and MSVCRT 6 C library: 4

On 1/8/06, Justin Haygood <jhaygood at spsu.edu> wrote:
>
> I was thinking, isn't there equivalent years like every 7 (or whatever it
> is) years or so? For negative year values, we simply could adjust it to an
> equivalent year, remember the year offset, and readjust to the correct year
> after letting localtime/gmtime do its magic?
>
> On 1/8/06, Maciej Stachowiak <mjs at apple.com> 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,
> > Maciej
> >
> >
> > On 1/8/06, Maciej Stachowiak < mjs at apple.com> 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,
> > > Maciej
> > >
> > >
> > >
> > > On 1/8/06, Maciej Stachowiak < mjs at apple.com> 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
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/webkit-dev/attachments/20060109/91694922/attachment.html