[MPlayer-dev-eng] [PATCH] Yet another batch of warning fixes :->

Arpi arpi at thot.banki.hu
Tue Dec 10 13:03:29 CET 2002


Hi,

> > >  typedef unsigned short  WORD;
> > > -typedef unsigned int    DWORD;
> > > -typedef unsigned int    ULONG;
> > > +typedef unsigned long   DWORD;
> > > +typedef unsigned long   ULONG;
> > >  typedef unsigned char   BYTE;
> > 
> > ARGH&*!%^#&*%@*&
> > 
> > it'll break code on 64bit platforms badly
> 
> Will it? How about uint32_t then? And avifile's loader has those
what is the problem with int ?

> defines exactly like in my patch.
yes and avifile is broken too. anyway avifile duplicates all those structs
with int (instead of DWORD) in its include/ dir, and us eit for non-x86 platforms.

> > > -		    printf("%.4s ", &c->fcc);
> > > +		    printf("%.4d ", c->fcc);
> > 
> > heh?
> > %.4d won't print fourcc but a silly number
> 
> Hmmm. Right, sorry, missed this one (although there's another done right).
another? where?

> -		    printf("%.4s ", &c->fcc);
> +		    printf("%.4s ", (char*)&c->fcc);
> 
> Better?
yes

> > > -	*lpFilePart = strrchr(lpFileName, '\\');
> > > +	lpFilePart = strrchr(lpFileName, '\\');
> > >      else
> > > -	*lpFilePart = lpFileName;
> > > +	lpFilePart = lpFileName;
> > 
> > looks bad
> 
> But it's not bad. lpFilePart is LPTSTR and that is char *.
imho it's char** (Long Pointer To STRing)

> > > +    InitializeQTML = (OSErr (*)(long))GetProcAddress(handler,
> > > "InitializeQTML");
> > 
> > WTF is this mess?
> 
> It casts the pointer returned by GetProcAddress to an appropriate pointer
> to a function, thus silencing "initialization from incompatible pointer
> type" warnings.
ah

> > > -//#include <string.h>      // FIXME: conflicts with fs.h
> > > +#include <string.h>      // FIXME: conflicts with fs.h
> >                                       ^^^^^^^^^^^^^^^^^^^
> 
> Oh, this one is interesting. I couldn't find any fs.h file on my system
> and in mplayer sources. WTF is it?

neither me, but some broken glibc versions / distribs had this problem.
a warning is still better than a non-compiling mplayer.

try to fix and see how many users will report it in next 10 minutes...
(or just check the archives)

> > and so on
> > 
> > do NOT apply this mess!
> 
> Geez, A'rpi. Of course I won't do it over your objections. No need to
> scream. :-P
> 
> > there are some good points but mostly broken stuff, and we're after -rc1...
> 
> Understood.

i'll merge some of them.


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu



More information about the MPlayer-dev-eng mailing list