header files that happen to have the same name as internal ones.
based on a patch by Vladislav Naumov, vladislav.naumov **at** gmail **dot** com
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@19426 b3059339-0415-0410-9bf9-f77b7e298cf2
patch replaces '()' for the correct '(void)' in function
declarations/prototypes which have no parameters. The '()' syntax tell
thats there is a variable list of arguments, so that the compiler cannot
check this. The extra CFLAG '-Wstrict-declarations' shows those cases.
Comments about a similar patch applied to ffmpeg:
That in C++ these mean the same, but in ANSI C the semantics are
different; function() is an (obsolete) K&R C style forward declaration,
it basically means that the function can have any number and any types
of parameters, effectively completely preventing the compiler from doing
any sort of type checking. -- Erik Slagter
Defining functions with unspecified arguments is allowed but bad.
With arguments unspecified the compiler can't report an error/warning
if the function is called with incorrect arguments. -- Måns Rullgård
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@17567 b3059339-0415-0410-9bf9-f77b7e298cf2
in both getch2 and getch2-win because only one of them is linked to.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@17248 b3059339-0415-0410-9bf9-f77b7e298cf2
- assert that the override param is nonzero (zero is not implemented)
- correct return value type to int
based on a patch by Diego
fixes bugzilla bug #342
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@17246 b3059339-0415-0410-9bf9-f77b7e298cf2
a simple 32 bits protected mode interface to some VESA functions. This
protected mode interface is interesting because it's quicker than the
raw int 10h interface.
Unfortunatly, begining with VBE 3.0, the 0x4f0a function is optional,
and some video cards don't implement it (3dfx, intel 845/855/865...).
This protected mode interface is then only used in vbeSetWindow and
vbeSetDisplayStart :
- vbeSetWindow already implement an alternative methode if protected
mode interface is not available.
- vbeSetDisplayStart also contain an alternative implementation, but
this one is disabled with a #if 0. I don't exactly know why because
it works well !
So currently, cards which don't have the 0x4f0a function are not
supported. This patch correct this.
- vbeGetProtModeInfo failure is not fatal.
- vbeSetDisplayStart has it's alternative implementation reenabled.
it's used only with cards which don't have the 0x4f0a function
so this won't make any difference for cards which were already
working.
This patch also make the failure of vbeGetModeInfo not fatal. The
VBE 3.0 standard state that GetModeInfo can fail with some mode
which are listed as supported if the mode can't be used in the
current situation (not enough video memory for example). So a
failure of vbeGetModeInfo don't mean that other modes won't work
and should really not be fatal.
patch by Aurelien Jacobs <aurel@gnuage.org>
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@13569 b3059339-0415-0410-9bf9-f77b7e298cf2
patch by Nicholas Kain, Alexander Strasser <eclipse7@gmx.net>
reviewed by Pontscho, Alex, Rich
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@12647 b3059339-0415-0410-9bf9-f77b7e298cf2
check for Glibc, not GNU.
patch by Robert Millan <zeratul2@wanadoo.es>
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@12064 b3059339-0415-0410-9bf9-f77b7e298cf2
attila
diego
ben
rfelker
reimar
rathann
ods15
al
albeu
alex
aurel
nplourde
faust3
wight