[Ffmpeg-devel] [PATCH] Fix some compiler warnings

Pieter Hollants pieter
Sat Jun 24 21:07:23 CEST 2006

Hash: SHA1

M?ns Rullg?rd schrieb:
>> The point is not to "hide" warnings which are there for a purpose, but
>> to fix them. Of course not const to non-const, perhaps I missed that
>> last night. To which hunk are you referring here?
> Most of them.

Right, I'll reinvestigate. But then, though my patches are wrong, it
means current code ain't right either, right?

>>>> for the byte shifting
>>>> operations I added the module operator, which makes sure the apparantly
>>>> desired shift results are reached without exceeding the variable's width.
>>> wtf?! RTF 5lines of code you changed, the code is perfectly fine for 
>>> FRAC_BITS from 0 to 8, and above 8 it will not work, your change might
>>> hide one of 2 warnings a FRAC_BITS of 9 should generate but it doesnt even
>>> partly fix the code in that case
>>> and FRAC_BITS is #defied to 8 
>> Accepted, but then what would be your suggestion to fix that part for
>> the mean time? Is it correct to change the if-statement into
>> "if(FRAC_BITS < 8)" and throw a #warning in an else-clause, until
>> someone steps up and fixes the whole thing for FRAC_BITS > 8?
> Huh?  C doesn't work like that.

Sorry, I meant something like assert().

Or what else would be a correct short-term fix? I understand that for
FRAC_BITS > 8 the whole code block needs more thinking, but seeing that
FRAC_BITS is currently defined to 8 - and I assume by purpose - let's do
an easy fix first, if possible.

- --
Pieter "Fate" Hollants <pieter at hollants.com>
(a current GnuPG key is available at www.hollants.com/gnupg.txt)
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the ffmpeg-devel mailing list