[Ffmpeg-devel] Matroska Patch
Thu Mar 23 10:10:35 CET 2006
On Wed, Mar 22, 2006 at 12:26:14AM -0500, Rich Felker wrote:
> On Tue, Mar 21, 2006 at 10:58:42PM +0100, Diego Biurrun wrote:
> > On Tue, Mar 21, 2006 at 04:53:44PM -0500, Rich Felker wrote:
> > > On Tue, Mar 21, 2006 at 08:21:33PM +0000, M?ns Rullg?rd wrote:
> > > > > For some reasons MSVC doesn't like a variable called time. It must
> > > > > be defined as a macro somewhere. And changing a name can't be such a
> > > > > bad change.
> > > >
> > > > Then figure out why. We don't support msvc, and will not accept
> > > > arbitrary patches to make it work without an explanation.
> > >
> > > ANSI/ISO C does not allow you to use "time" as a symbol name with
> > > external linkage, but it's totally valid to use it as a local variable
> > > or with static linkage. If MSVC chokes on this, tough. MSVC users can
> > > add -Dtime=MSVC_sucks_time to their compiler options...
> > Or we could just rename the variable and make everyone's life a bit
> > easier. IMO this is one of the cases where we should budge.
> 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
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. In this situation avoiding time as variable name outright
looks like the clean solution to me.
@Steve: Variable renaming should go in a separate patch in any case.
More information about the ffmpeg-devel