[Ffmpeg-devel] Matroska Patch

Steve Lhomme steve.lhomme
Fri Mar 24 20:29:15 CET 2006


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 ?

Steve





More information about the ffmpeg-devel mailing list