[FFmpeg-devel] [PATCH] Fix warnings in decode_significance_x86 and decode_significance_8x8_x86 (in h264_i386.h)

Michael Niedermayer michaelni
Tue Jul 6 14:10:48 CEST 2010


On Tue, Jul 06, 2010 at 02:06:41PM +0200, Michael Niedermayer wrote:
> On Tue, Jul 06, 2010 at 12:34:55PM +0100, M?ns Rullg?rd wrote:
> > Michael Niedermayer <michaelni at gmx.at> writes:
> > 
> > > On Mon, Jul 05, 2010 at 08:02:09PM -0700, Eli Friedman wrote:
> > >> On Sat, Jul 3, 2010 at 10:07 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> > >> > On Thu, Jul 1, 2010 at 9:46 AM, Eli Friedman <eli.friedman at gmail.com> wrote:
> > >> >> On Sun, Jun 27, 2010 at 4:17 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> > >> >>> On Sun, Jun 27, 2010 at 3:53 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > >> >>>> On Sun, Jun 27, 2010 at 01:33:01PM -0700, Eli Friedman wrote:
> > >> >>>>> 2010/6/27 M?ns Rullg?rd <mans at mansr.com>:
> > >> >>>>> > Eli Friedman <eli.friedman at gmail.com> writes:
> > >> >>>>> >
> > >> >>>>> >> Patch attached; adds extra casts so gcc doesn't warn about truncating
> > >> >>>>> >> pointers.
> > >> >>>>> >
> > >> >>>>> > Do you mean "implicit conversion of pointer to integer of different size"?
> > >> >>>>>
> > >> >>>>> Yes.
> > >> >>>> [...]
> > >> >>>>> Okay, second try attached.
> > >> >>>>
> > >> >>>> if this generates identical object files: then i abstain from commenting
> > >> >>>> if it changes object files to being slower then i object to this change
> > >> >>>
> > >> >>> This generates identical object files, at least on gcc 4.4.
> > >> >>>
> > >> >>
> > >> >> Ping.
> > >> >
> > >> > PINGPINGPINGPINGPING.
> > >> >
> > >> 
> > >> This is completely ridiculous: this tiny patch hasn't had any response
> > >> in over a week!
> > >
> > > can someone please take care of tiny patch, play with it, feed it, make
> > > sure its not just sitting lonely and sad in the corner
> > > you guys are so cruel
> > 
> > I'm fine with the patch, but I'm not maintainer of that file, you are.
> 
> Didnt you say "Double casts are almost always the wrong solution." ?
> 
> its still doing pointer -> intptr_t -> int, one cast is implict but there are
> still 2 casts.
> i dont care really as long as compilers dont generate extra instructions,
> you where the one being against double casts, not that i like them 

Also as we are already speaking of this, how exactly should one cast from
a 64bit pointer to int32_t in cases where exactly this is needed?
i mean if the compiler just doesnt like this opperation, the solution
with "obfuscating it through a intermediate step really feels ugly to me.


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100706/a20f9832/attachment.pgp>



More information about the ffmpeg-devel mailing list