[Ffmpeg-devel] Re: [Ffmpeg-cvslog] r8420 - trunk/libavcodec/dv.c

Rich Felker dalias
Mon Mar 26 04:07:36 CEST 2007


On Mon, Mar 26, 2007 at 09:51:01AM +1000, John Dalgliesh wrote:
> On Sun, 25 Mar 2007, Rich Felker wrote:
> >On Sun, Mar 25, 2007 at 03:40:22PM +0300, Uoti Urpala wrote:
> >>I think the only sane way to work with the current gcc is to assume that
> >>the stack _will_ be 16-byte aligned inside FFmpeg. If there are problems
> >
> >This is blatently incorrect though, and not dependent on gcc. Even if
> >you use gcc 4.x, my crt0/libc does not align the stack, and will not
> >align the stack, ever. It's wasteful and stupid. You can't just make
> >nonportable assumptions based on what one OS does incestuously with
> >latest gcc.
> 
> What exactly is the problem here? Yes technically the ABI only requires 
> 4-byte aligned stack. And yes gcc doesn't seem capable of aligning to 
> better than the stack alignment. But this doesn't affect the correctness 
> of the code!

It does!

> So _if_ you encounter a platform with stack alignment problems, your 
> choices are either:
> - Use a compiler that can align properly (or fix gcc)

And tell everyone to upgrade to the fixed one... (Not to mention the
devs won't even fix it to begin with because they don't consider it
broken.)

> - Work around gcc's deficiency in the platform ... 'incestuously' if you 
> must

You mean the platform should change to accomodate gcc brain damage?
Not going to happen. There are plenty of legacy platforms that will
never change, and as for mine, I have no interest in sleeping with
gcc.

> - Send patch with workaround to ffmpeg devs and compelling argument for 
> your case
> 
> I don't like your chances with option 3 'tho given what I remember of the 
> response the last time this came up (ffmpeg called from some Windows 
> compiler).

No, this is a case of using a nonportable gcc feature to begin with
(alignment). There are portable ways to do the same thing (allocate
more space than you need and manually align it). Using the portable,
always-working method is not a workaround or hack. It's a
fundamentally better approach than relying on a nonstandard gcc
extension that's not even implemented correctly in gcc.

> But regardless, the only way you can call it nonportable is if you also 
> make the (nonportable) assumption of using broken gcc.

No, it's nonportable because there's at least one environment in which
it breaks, not because I assume it breaks everywhere (which I don't).
No assumptions are being made here.

Rich




More information about the ffmpeg-devel mailing list