[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

[Uoti Urpala]

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:

>> 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;};

a.c:
#include "header_a.h"
#include "common.h"
int bfunc(struct s x);
int foo(struct s x)
{
    return bfunc(s);
}

b.c:
#include "header_b.h"
#include "common.h"
int bfunc(struct s x)
{
    return s.a;
}