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

[Baptiste Coudurier]

On 2/5/2009 2:18 PM, Reimar D?ffinger wrote:
> On Thu, Feb 05, 2009 at 02:07:18PM -0800, Baptiste Coudurier wrote:
>> On 2/5/2009 1:03 PM, Reimar D?ffinger wrote:
>>> On Thu, Feb 05, 2009 at 09:15:18PM +0100, bcoudurier wrote:
>>>> +static uint64_t mxf_parse_timestamp(time_t timestamp)
>>>> +{
>>>> +    struct tm *time = localtime(&timestamp);
>>>> +    return (uint64_t)(time->tm_year+1900)<<   48 |
>>>> +           (uint64_t)(time->tm_mon+1)<<   40 |
>>>> +           (uint64_t) time->tm_mday<<   32 |
>>>> +                      time->tm_hour<<   24 |
>>>> +                      time->tm_min<<   16 |
>>>> +                      time->tm_sec<<   8;
>>>> +}
>>> Huh, the time is stored in a timezone-dependent format without storing
>>> the time zone?
>> Seems so, anyway I don't make the specs.
>>
>> Besides which format specifies the time zone ?
>> mov/mp4 doesn't, at least.
>
> I would assume if they don't specify a time zone they use UTC/GMT.

Well my reader does not convert anything when diplaying stored time.
I don't know.

>>> Anyway, you can not use localtime, it is not thread-safe.
>> localtime is used in libavformat parse_date, though this is not an
>> argument. How important is the thread safety here ?
>> It is really not like time having 1 second difference is a problem, no ?
>
> 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.

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

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