I believe that's wrong behavior. GetImage is spec'd that way.
PutImage is not.
Mark.
On Thu, 18 Dec 2003, Alan Hourihane wrote:
> Looking at ProcShmGetImage() there's a bunch of checking for out-of-bounds
> coordinates, but ProcShmPutImage() lacks this checking.
>
>
On Thu, Dec 18, 2003 at 09:56:01AM -0800, Keith Packard wrote:
> 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 limit
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.
___
Dev
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
=
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
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
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
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
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
th