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

[Rich Felker]

On Sun, Mar 25, 2007 at 03:40:22PM +0300, Uoti Urpala wrote:
> On Sun, 2007-03-25 at 12:06 +0100, Guillaume POIRIER wrote:
> > On 3/25/07, Roman Shaposhnik <rvs at sun.com> wrote:
> > > On Fri, 2007-03-16 at 00:45 +0100, gpoirier wrote:
> > > > -    assert((((int)block) & 7) == 0);
> > > > +    assert((((int)block) & 15) == 0);
> > >
> > >   Are you sure this works? I see no way of aligning anything on the
> > > x86 stack for more than 8. And even that is kind of iffy, given
> > > that the x86 ABI mandates an alignment of 4.
> 
> The de facto ABI on current Linux is 16 byte stack alignment.

De facto my ass. ANY i386 ELF or a.out .o file is usable on current
Linux, and may in fact be present. Just because no such objects come
with your latest fedora/gentoo/ubuntu/whatever doesn't mean that you
can pretend they don't exist. The i386 ABI has 4 byte alignment.
Period. This is all you can assume.

Any assumptions based on ABI are broken anyway unless they're being
made by someone who has FULL control over the relevant aspects of the
ABI. gcc does not have such control and thus it cannot make such
assumption.

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

Rich