[FFmpeg-cvslog] r18896 - trunk/libavcodec/eatgq.c
Sat May 23 18:46:08 CEST 2009
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
> 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
I think it's time YOU got back in touch with reality, a reality which
contains vastly more than gcc/linux/x86.
mans at mansr.com
More information about the ffmpeg-cvslog