On Wed, Dec 17, 2003 at 03:08:03PM -0800, Mark Vojkovich wrote:
I don't think it's as bad as you think. It looks to me like
this comes about due to a difference in the Shm protocol. Going
against convention, xShmPutImageReq has an unsigned value for the
src X and Y location. All other
Looking at ProcShmGetImage() there's a bunch of checking for out-of-bounds
coordinates, but ProcShmPutImage() lacks this checking.
Is this patch reasonable or too much (it does fix the problem) but I'm
wondering if the bounds are too strict for PutImage ?
Alan.
Index: shm.c
Around 14 o'clock on Dec 18, Alan Hourihane wrote:
Is this patch reasonable or too much (it does fix the problem) but I'm
wondering if the bounds are too strict for PutImage ?
Preserved window contents may not be limited to screen geometry.
___
Having looked at Bugzilla #978 it shows that it's very easy to crash
the Xserver when using out-of-bounds coordinates that get mixed up when
passing in int's that get converted to short's during the client-server
conversation.
Seeing as PutImage gets pushed through the CopyArea path, I'm sure
I don't think it's as bad as you think. It looks to me like
this comes about due to a difference in the Shm protocol. Going
against convention, xShmPutImageReq has an unsigned value for the
src X and Y location. All other primitive have signed values.
I think the correct behavior is probably
Ah yes. I skimmed over shmstr.h too quickly and assumed INT16 instead
of CARD16 for the source coords.
I'll try this now.
Alan.
On Wed, Dec 17, 2003 at 03:08:03PM -0800, Mark Vojkovich wrote:
I don't think it's as bad as you think. It looks to me like
this comes about due to a difference
On Wed, Dec 17, 2003 at 03:08:03PM -0800, Mark Vojkovich wrote:
I don't think it's as bad as you think. It looks to me like
this comes about due to a difference in the Shm protocol. Going
against convention, xShmPutImageReq has an unsigned value for the
src X and Y location. All other
