[comp.windows.x] Bugs in XFetchBytes/XStoreBytes

wjh+@ANDREW.CMU.EDU (Fred Hansen) (12/02/89)

The implementations of XFetchBytes and XStoreBytes ignore
display->max_request_size, so they fail if the string argument is too
large.

Here is a sketch of what XStoreBytes ought to look like:


	Display *xDisplay = /*** the display ***/ ;
	Window window =  RootWindow(xDisplay, 0);
	long l;
	char *x;
	int mode = PropModeReplace;
	int maxxfer = xDisplay->max_requestsize - 100;

	l =  /*** length to send ***/  ;
	x =  /*** source location ***/ ;
	while (l > 0) {
		/* send a chunk of bytes */
		XChangeProperty(xDisplay, window, XA_CUT_BUFFER0,
			XA_STRING, 8, mode, (unsigned char *) x, 
			(l > maxxfer) ? maxxfer : l);
		l -= maxxfer;
		x += maxxfer;
		mode = PropModeAppend;  /* mode for subsequent transfers */
	}

rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (12/02/89)

Perhaps they should just be moved to an "Andrew compatibility appendix". :-)

mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) (12/02/89)

> Here is a sketch of what XStoreBytes ought to look like:

Not to get overly pedantic, but....

(severely edited down)
> 	char *x;
> 	x =  /*** source location ***/ ;
> 	while (l > 0) {
> 		x += maxxfer;
> 	}

...the x += maxxfer may cause undefined behavior.  Addresses outside of
arrays do not have to be even computable (except for the special case
of one beyond the last element).  Therefore, if the array supplied by
the user does not extend far enough past the last element to be sent,
this may coredump (or worse), because the addition will generate a
pointer outside the array.

To be sure, this isn't a problem on sane machines, but not all machines
are sane, and X is supposed to be excessively portable.

(I must admit, Fred did call this a "sketch".)

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu