On Mon, Jun 10, 2013 at 11:41:00 +0200, Daniel Martin wrote: > On 9 June 2013 19:00, Julien Cristau <jcris...@debian.org> wrote: > > The padding is *before* the rate field, so the rate is placed on a 32bit > > boundary. This change adds explicit padding between height and rate, > > and removes extraneous padding after the rate field, which the server > > never sent and xlib never read. > > > > This changes sizeof(xvEncodingInfo). Hopefully that's not a big deal as > > clients only see the Xlib structure XvEncodingInfo. > > (Hopefully, I'm right with that): > I think that's an ABI change and a bit more difficult. Think about an X > server, which is compiled against a xvproto version without that change > and the lib compiled against xvproto with that change. In that case the > lib would start to read the encoding info, where the X server just sended > those extraneous pad bytes. > No. As said in the commit message, the server never sent the extraneous pad bytes, so this patch doesn't change either the server or libXv behaviour. Both it and libXv use sz_xvEncodingInfo, which is ok.
> I just saw that the reply structure itself (xvQueryEncodingsReply) has > such extraneous padding too: > ... > CARD32 length B32; > CARD16 num_encodings B16; > CARD32 padl3 B32; > ... > And even without this padding sz_xvQueryEncodingsReply=32 is wrong, > as the fields sum up to 34 and with that padding we're at 36. > Looks like padl3 should really be CARD16... Cheers, Julien -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130610095538.ga2...@coloquinte.cristau.org
