[Ffmpeg-devel] Matroska Patch
Fri Mar 24 19:22:51 CET 2006
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.
More information about the ffmpeg-devel