The xcb_get_property_value_length function returns a unit count, where one might expect a byte count instead. Unless I am mistaken, every other xcb_*_length function (that is not associated with an iterator) returns a byte count. Unfortunately, fixing this would either require a set of iterators (one for each possible property size?), or breaking all existing users of the xcb_get_property_value_length function. I am using version 1.0-19-gbca41cd, but I don't see any relevant changes to c-client.xsl between then and 1.1. Barton C Massey <bart@cs.pdx.edu> asked me to open this bug.
No, all of the _length functions should be returning the length of the list in number of elements, not number of bytes. In your mail, you point out that xcb_get_image_data_length returns a length in bytes, not in pixels, which would seem like a natural definition of element units for that request. GetProperty and GetImage are strange cases since the element size is not, in general, known statically. GetImage is particularly confusing because pixels aren't always packed one after another, due to various kinds of padding on each row. At some point in the distant past, I guess I decided that GetImage couldn't be naturally used with anything but a length in bytes--while GetProperty would be unnatural to use with anything but a length in units. At this point, even if we decide that there's a natural unit size for all GetImage responses, changing it would be an API/ABI change, which we've committed to not doing. So GetProperty is working as designed, and GetImage may be broken as designed, and we're unlikely to do anything about either. I hope that makes the design decisions clearer.
Hmm. I see. I just remember being surprised when I was writing my lua xcb binding. I'd submit a patch against c-client.xsl to improve the generated documentation, but it's about to be obsoleted by the python replacement. Thanks for explaining the design decision.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.