[FFmpeg-cvslog] r17011 - trunk/libavformat/mxfenc.c

[Reimar Döffinger]

On Thu, Feb 05, 2009 at 03:04:41PM -0800, Baptiste Coudurier wrote:
> > Huh? Why onw second time difference? The point is that when by chance
> > the user application calls localtime at the same time as libavformat
> > both will get a random combination of both times.
> > I'd say these functions should be added to the forbidden-functions list
> > like printf etc.
> 
> Between the call and the actual use of the value, not considering both 
> calls which would have which would cause the year/day/month to be wrong, 
> which is not security critical, but might be annoying I reckon.

You can't know if this is security-critical without knowing what the
application using ffmpeg does.
Fact is that it causes a side-effect which changes global state - other
functions like random() were forbidden for this reason.

> I've checked support or _r variants, but mingw seems to not have it, it 
> seems win32 localtime is safe (?)

How should that be possible? localtime returns a pointer which was not
allocated by the caller, and thus can never be freed.
So either localtime has a giant memleak or it always uses the same
buffer. Even if it used thread-local store, that possibly would not be
thread-safe with some (particularly ugly) kinds of userspace threading
(i.e. where there is a "virtual" threading implemented via jumps within the
application, not using the kernel scheduler).
Unfortunately it seems that indeed the Microsoft C lib does not provide
thread-safe versions.
Btw. I am against localtime because that means when transcoding (once
we support transferring this information) the result will depend on
the local time zone (even when both source and destination are MXF, due
to summer time, conversion localtime -> time_t -> localtime is not
lossless - I think).