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

[Eli Friedman]

On Tue, Jul 6, 2010 at 5:18 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Tue, Jul 06, 2010 at 02:10:48PM +0200, Michael Niedermayer 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.
>
> and then with next version the compiler becomes smarter and sees through the
> double cast and recognizes we still do a 64p -> 32i cast so we change that
> then to a 64p->64i->rsa encrypt -> rsa decrypt->32i ?
> the rsa code written in asm() of course and the keys or both sides rerieved
> at runtime from somewhere so the compiler cant know they match
>
> if only the compiler could read then we could add a
> // we are casting from a possibly 64bit pointer to 32bit int

If you prefer, there's -Wno-pointer-to-int-cast... it's normally meant
to catch portability problems, but that sort of thing seems unlikely
to creep into ffmpeg.

-Eli