[Ffmpeg-devel] Matroska Patch

Måns Rullgård mru
Fri Mar 24 21:22:37 CET 2006

Steve Lhomme <steve.lhomme at free.fr> writes:

> M?ns Rullg?rd wrote:
>> Rich Felker <dalias at aerifal.cx> writes:
>>> On Fri, Mar 24, 2006 at 01:22:29AM +0000, M?ns Rullg?rd wrote:
>>>> Rich Felker <dalias at aerifal.cx> writes:
>>>>> On Thu, Mar 23, 2006 at 10:10:35AM +0100, Diego Biurrun wrote:
>>>>>>> I disagree strongly. Renaming variables because of a broken compiler
>>>>>>> simply hides bugs in the compiler. If people keep seeing that they
>>>>>>> have to make workarounds when using broken compilers maybe they'll
>>>>>>> complain to the compiler vendor or switch to a standards-compliant
>>>>>>> compiler. If we just hide the bug it encourages people to use this
>>>>>>> crap.
>>>>>> This case is different IMO.  The use of 'time' as variable name is
>>>>>> problematic.  You have to have a copy of the C standard lying around to
>>>>>> check which uses are allowed and which aren't to avoid shooting yourself
>>>>>> in the foot.
>>>>> No you don't. It's very clear. You're not allowed to use names from
>>>>> the C library as external symbols. Any other use is just fine as long
>>>>> as you don't include the header (in this case time.h).
>>>> Even if you do include the header, using the names in local scope is
>>>> fine, with the exception of object-like macros.  Standard library
>>>> functions are not allowed to be defined by the system headers as
>>>> object-like macros, so using "time" as a local variable name will
>>>> never be problematic in a conforming environment.  The C99 standard
>>>> makes this quite clear in sections 7.1.3-4.
>>> Are you sure? I was going by SUSv3 which is supposedly aligned with
>>> ISO C99. Reading the C99 draft, I have:
>>>        7.1.4  Use of library functions
>>>        [#1] ................................................... Any
>>>        function   declared   in   a   header  may  be  additionally
>>>        implemented as a function-like macro defined in the  header
>>> I suppose this cannot cause conflicts with local variables though
>>> since () is never valid after a variable name.
>> Yes, function-like is the opposite of object-like when talking about
>> macros.
> So, everybody agrees that block_time is a better mnemonic ?

It might be marginally better.  Given that the function where it is
used parses blocks, there is little else it could mean.

What exactly goes wrong if it is called "time"?

M?ns Rullg?rd
mru at inprovide.com

More information about the ffmpeg-devel mailing list