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

[Baptiste Coudurier]

On 2/5/2009 3:46 PM, Reimar D?ffinger wrote:
> 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'm not so familiar with thread safety, so you may be right. Can you 
explain a potential harmful scenario ?

>> 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).

I can understand the thread-local store, here people using the virtual 
mechanism are really looking into problems by using localtime.

> 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).

For now, since my application reads the time "as is", Im against using 
GMT time, unless stated in specs.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
FFmpeg maintainer                                  http://www.ffmpeg.org