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

[Michael Niedermayer]

On Tue, Jul 06, 2010 at 12:04:33PM -0700, Eli Friedman wrote:
> 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.

Iam strongly in favor of adding -Wno-pointer-to-int-cast
Its all fine if the compiler complains about odd implicit conversion
but complaining about an explicit cast is going too far, the assumtation
that the programmer knew what he was doing seems reasonable

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
-------------- 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/20100707/1cef6b1f/attachment.pgp>