[MPlayer-cvslog] r26175 - in trunk/libmpdemux: demux_avs.h demuxer.h ebml.h matroska.h mp3_hdr.h mpeg_packetizer.h muxer.h parse_es.h stheader.h
Reimar Döffinger
Reimar.Doeffinger at stud.uni-karlsruhe.de
Thu Mar 6 19:57:51 CET 2008
On Thu, Mar 06, 2008 at 08:19:59PM +0200, Uoti Urpala wrote:
> On Thu, 2008-03-06 at 09:06 +0100, Reimar Döffinger wrote:
> > On Thu, Mar 06, 2008 at 03:33:30AM +0200, Uoti Urpala wrote:
> > > On Thu, 2008-03-06 at 01:59 +0100, Diego Biurrun wrote:
> > > > libmpdemux/aviheader.h and loader/wine/avifmt.h have duplicate
> > > > declarations with conflicting types.
> >
> > This is neither a bug nor has anything been uncovered. We even discussed
> > this in detail during the format-string fixes, and this is just what you
> > have to expect when going for the quick hack instead of a real "fix" just
> > like everyone else has done for years.
>
> This alone is not a bug. But you clipped the part of my reply to Diego's
> mail that explained the bug:
I clipped stuff because I actually wanted to answer to Diego only, but
due to some email-messup that one went missing (or at least arrived only
much later)...
> >> And the actual bug (the uncovered one, not this commit breaking
> >> compilation...) is that muxer.h depends on other headers to define types
> >> like AVIStreamheader, which are then used in fields of shared structs.
>
> >> Thus there were incompatible definitions of a shared type in different
> >> .c files.
>
> Having incompatible definitions for a similarly named type is not
> automatically a bug. Using those incompatible definitions as part of the
> definition of a shared type which must be compatible between files IS a
> bug. If this isn't clear here is an example:
>
> header_a.h: typedef int avitype;
> header_b.h: typedef long avitype;
>
> The existence of these headers alone is not yet a bug. However this is:
>
> common.h: struct s {avitype a;};
Those two definitions may be syntactically different, but MPlayer both in
loader and in libmpdemux _needs_ that they have a certain, fixed memory
layout, so this is not a bug in the sense that it can cause any
(additional) problems.
More information about the MPlayer-cvslog
mailing list