[FFmpeg-devel] parse_date using localtime etc.

Reimar Döffinger Reimar.Doeffinger
Fri Feb 6 12:49:20 CET 2009

On Fri, Feb 06, 2009 at 11:53:51AM +0100, Michael Niedermayer wrote:
> On Fri, Feb 06, 2009 at 11:11:05AM +0100, Reimar D?ffinger wrote:
> > as it came out during a recent discussion, parse_date uses the
> > non-thread-safe functions localtime and gmtime.
> > This is not much of an issue currently, since libav* does not use that
> > code path.
> > However I still have a bad feeling about it, since libav* functions are
> > expected to not have global side-effects and to be thread safe.
> > The question is what to do about it.
> use localtime_r()

Not available on MinGW. Though you could use localtime_s, while MinGW
does not declare it in their headers it should work...
So how should this be solved,
#ifdef __MINGW32__
#define localtime_r(time, tm) localtime_s(tm, time)
(this is not 100% since localtime_s returns errno_t, not tm), this can
be fixed by making it a function but will cause clashes if localtime_r
is implemented in MINGW.
Or make an av_localtime_r?

> besides it has to be mentiond that some libcs like microsofts according
> to google provide a thread safe localtime() with thread local storeage.

That does not solve anything (actually it creates even _more_ issues)
since you could pass the pointer to a different thread.
Well, it "solves" one thing, you can use it to implement a correct

> And IMO having a thread safe libc in addition to a unsafe one would have
> been nicer for posix instead of duplicating functions with differnt API.

The thread safety issue is _unsolvable_ (except for some special cases)
with such broken APIs as localtime.

Reimar D?ffinger

More information about the ffmpeg-devel mailing list