RE: OPENSSL_gmtime on platforms that don't have a safe gmtime function - Openssl

This is a discussion on RE: OPENSSL_gmtime on platforms that don't have a safe gmtime function - Openssl ; Hi,
> >why not use mutexes to wrap the gmtime and memcpy,
> >like other places in the library?
>
> Because it is either needless or insufficient.
(snipp)
> On platforms where thread-specific
> data is not used, the ...

RE: OPENSSL_gmtime on platforms that don't have a safe gmtime function

Hi,
> >why not use mutexes to wrap the gmtime and memcpy,
> >like other places in the library?
>
> Because it is either needless or insufficient.
(snipp)
> On platforms where thread-specific
> data is not used, the mutexes would not prevent other code (not part of
> OpenSSL) from calling these functions in-between when OpenSSL calls them =
and
> when the returned data can be used or copied.

Well, while it is still insufficient, mutexes would allow a user calling
OpenSSL functions from multiple threads to do so without having to worry ab=
out
all the internals, like "do function a() and b() both use gmtime internally=
,
so a common mutex around those two function calls is needed?" Not to mentio=
n
that in a cross-platform application it's going to be needed on a few platf=
orms
only, while on most it will work without them. Ensures interesting testing =
and
debugging sessions, IMO.
Of course, if the user is calling gmtime himself, he still needs to know su=
ch
stuff, but that might be less common than calling two openssl functions tha=
t
end up calling gmtime. Also, you could add a warning in such case that any
multi-threaded application needs to wrap their gmtime calls with such and s=
uch
mutex.

OTOH, if you have two or more libraries taking this approach, each using a
gmtime wrapper with its own mutex, that's possibly going to be more confusi=
ng
than helpful.