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

[Måns Rullgård]

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.

> 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.

> 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.

> in particular having a look at any of these functions:
> ff_check_alignment dct_sad8x8_c dv_decode_video_segment tqi_decode_frame
> h263_skip_b_part dct_quantize_refine apply_mdct rtjpeg_decode_frame_yuv420
> render_slice
>
> I think I can quickly "fix" tqi_decode_frame and rtjpeg_decode_frame_yuv420
> but I don't see the point if the others will probably stay as they are
> now for years, unless someone else makes an effort.

I have fixed several such cases in the past when I have come upon
them.  I don't have time to audit the code for other potential failure
cases.

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

-- 
M?ns Rullg?rd
mans at mansr.com