[Xcb] uninitialized byted when a connection is created

[Jamey Sharp]

On Sun, 2005-05-15 at 18:42 -0400, Jeremy Kolb wrote:
> Jamey Sharp wrote:
> > XCB has a handful of different valgrind warnings about uninitialized
> > writes, because it doesn't initialize most padding bytes.
> 
> So... is it zeroed out or not?

Emphasis on "most" :-) though I don't actually know the relative
frequency of the bytes it zeroes compared to the ones it doesn't. The
code you quoted (and IIRC some related code that handles a slightly
different case in writev calls) only zeros padding bytes at the end of
chunks pointed to by some struct iovec. What that omits is generally
anything that is declared with a <pad> tag in the XML protocol
description.

It turns out that you have to pad the end of PolyText requests with
zeros, because otherwise the garbage might be interpreted as more text
or a font change. (I imagine a single initialized 0 byte plus one or two
more uninitialized pad bytes, as needed, would actually suffice.) There
may be some other similar examples. This is why XCB zeroes some padding.
The rest has no impact on correctness, so XCB doesn't have that extra
little bit of ugly code zeroing things.

> This actually popped up on #freedesktop the other day, someone wanted to 
> know if xcb zeroed out the queue since ssh and others apparently benefit 
> greatly.

I would love to see evidence of this claim. Let's just say it's not
intuitively obvious to me. I could give all sorts of reasoning, but I'd
rather see numbers.

Of course, as Keith's paper showed, latency is the remote performance
killer for X, so I have a lot of trouble getting excited over a minor
bandwidth tweak.

--Jamey