I've just checked in a change to SDODate.cpp so that we define a macro
called tuscany_localtime_r and set it to whichever is appropriate for Linux
or MS VC8 and then use the macro wherever we would have called localtime.
The macro is guarded by an #ifndef so you can override it with a compiler
switch if needs be.

Regards,

Geoff.

On 20/12/06, Caroline Maynard <[EMAIL PROTECTED]> wrote:

On 14/12/06, Geoffrey Winn <[EMAIL PROTECTED]> wrote:
>
> I've just checked in the change for localtime, replacing it with
> localtime_r
> on Unix and localtime_s on Windows.


Ah. Unfortunately this is a backward compatibility issues with MS
compilers.
localtime_s() does not exist in VC++ 6. But localtime() is deprecated in
VC++ 8 in favour of localtime_s(). See

http://groups.google.com/group/comp.lang.c++.moderated/browse_frm/thread/f712f39b702000af
?

Unless you intend to drop support for VC++ 6 users, you'll need to use a
preprocessor macro, like _MSC_VER*, *to check which function  to use.

In case you're wondering how the PHP engine does this, it defines a macro
php_localtime_r, which is always used internally in place of any localtime
variant. This uses localtime_r, if it is available. If the system doesn't
have localtime_r, then it uses localtime but adds its own locking around
the
call. It never invokes localtime_s. Gory details in
http://cvs.php.net/viewvc.cgi/php-src/main/reentrancy.c.

You may deduce from this that the best solution for me would be if you
were
to introduce, say, tuscany_localtime_r, to do whatever you want to do for
your general user, and which I could then redefine to php_localtime_r.

--
Caroline


Reply via email to