[Xcb] zeroing out

Jeremy A. Kolb jkolb at brandeis.edu
Sat Dec 31 07:38:47 PST 2005


Why can't we just extract the string and force a null at the end and 
return it when calling the XCBExtString function?  I think that would be 
easier than requiring people using XCB to write and use their own 
functions for every single string returned.  The API is hard enough to 
read already and I think it would be a win in the useability department.

Jeremy

On Fri, 30 Dec 2005, Barton C Massey wrote:

> Sounds like in principle, significant null bytes could
> appear in some count/chars strings sent by the X server.  In
> practice I would be shocked, but that's standards for you.
> 
> What we probably want is a few convenience functions in XCB
> for dealing with these things, like the nstrcmp() [horrible
> name, maybe not right API] I wrote for xcbxvinfo.  I'm not
> sure what else to do, really...
> 
> 	Bart
> 
> In message <Pine.LNX.4.44.0512302159230.20006-100000 at diane.unet.brandeis.edu> you wrote:
> > On Fri, 30 Dec 2005, Keith Packard wrote:
> > 
> > > On Fri, 2005-12-30 at 16:49 -0800, Barton C Massey wrote:
> > > 
> > > > Anyone remember offhand whether null bytes are allowed in
> > > > the count/chars strings returned by X requests?  Anyone know
> > > > whether there must be a space in the reply for a trailing
> > > > null byte?  If either of these things are wrong, then XCB
> > > > isn't reasonably going to be able to return C strings...
> > > 
> > > Strings in X replies are not nul terminated. Xlib allocates an extra
> > > byte for 8-bit properties and stuffs a nul in there.
> > > 
> > > -keith
> > > 
> > > 
> > 
> > Is there any reason we would not need to return a NULL terminated string?  
> > It seems like that is something we should provide to prevent a lot of 
> > duplicated code client side.
> > 
> > Jeremy
> 



More information about the Xcb mailing list