[Ffmpeg-devel] Matroska Patch

[Måns Rullgård]

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