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

[Alex Converse]

On Tue, Jul 6, 2010 at 8:10 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> 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.
>

Excuse my ignorance but why is a 64bit pointer conversion to int32_t
needed/acceptable here in the first place?

1075     significant_coeff_ctx_base = h->cabac_state
1076         + significant_coeff_flag_offset[MB_FIELD][cat];

cabac_state is an offset in the context. How do we know it will fall
in the bottom 32-bits of our address space?

Thanks,
Alex