[FFmpeg-cvslog] r18896 - trunk/libavcodec/eatgq.c

[Reimar Döffinger]

On Sat, May 23, 2009 at 05:46:08PM +0100, M?ns Rullg?rd wrote:
> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
> 
> > On Sat, May 23, 2009 at 04:25:11PM +0100, M?ns Rullg?rd wrote:
> >> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
> >> > So it seems to me that the commit message is quite accurate, even if
> >> > we might want to avoid aligned data on the stack completely in the
> >> > future.
> >> 
> >> Aligning stack variables is either possible or impossible.  Unreliable
> >> is equivalent to impossible.  The commit message is misleading.
> >
> > No, unreliable meant "possible, but probably several compilers we might
> > like to support are broken, so it is better to avoid it".
> 
> It is known to fail on several compilers/systems we *do* support right
> now.  For instance, regression tests are failing on Sparc and Blackfin
> because of such invalid assumptions.

Are there proper bug reports for them? The FATE machine seems to have
more issues than that. If not only other issues.

> > Also I find your assertion that aligning for 8 bytes is always on any
> > architecture absolutely reliable more than questionable.
> 
> I never made that assertion.

True, I misunderstood it so because of the way you said it. That would
add two more functions to the "to be fixed" list then.

> > If you insist I can extend the commit message into such extended prose,
> > but I really think such details would be more appropriate in some
> > developer reference.
> > Particularly since it seems to me that your view of FFmpeg code is
> > severely out of touch with reality,
> 
> I am well aware of the existence of flawed code presently in FFmpeg.
> This is no excuse for adding even more of it.

Would you or someone else volunteer to add a section to the coding
documentation? That's one of the better ways to avoid that in the
future.
Still, given the code you reply to I think we are on the same side on
this, just looking at the data I have this looks like a very minor issue
_in practice_.

> I think it's time YOU got back in touch with reality, a reality which
> contains vastly more than gcc/linux/x86.

Well, you misunderstood my point:
1) What I consider core parts of FFmpeg relies on alignment on stack, so
it can't really be that bad in reality
2) It makes it look far less obvious to me what the "official" FFmpeg
position is: are the compilers buggy (as that one message we still print
says) and that's not our problem or should the code be changed?

Obviously it is not so simple. Apart from that I fear that reality
(unfortunately) actually does not contain much more than gcc/linux/x86
(well, at least any two of those three).
And looking at FATE, it seems to me that even on the "strange"
architectures more errors come from something else, not stack alignment
issues...