Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!think.com!mintaka!bloom-beacon!dont-send-mail-to-path-lines
From: rws@expo.lcs.mit.EDU (Bob Scheifler)
Newsgroups: comp.windows.x
Subject: Re: Ambiguity or errors in protocol specification
Message-ID: <9101291435.AA19632@expire.lcs.mit.edu>
Date: 29 Jan 91 14:35:03 GMT
References: <9101281954.AA09857@sparc.com>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 76

Not obvious why you point the finger at the protocol spec for most of these.

    The second client performs GrabKeyboard, GrabModeAsync, 
    expecting to see a reply with status GrabFrozen
    Instead, a reply with status AlreadyGrabbed results.

Correct.

    "The request fails with status Frozen if the keyboard is frozen 
    by an active grab of another client."

The sentence just before this one takes precedence (that's why it comes first).

    The definition of
    UngrabKey doesn't mention this at all, which may be an
    intended omission

Since it is not mentioned, it should be viewed as an intended omission,
so no error should be expected.

    My test program makes liberal use of GetWindowAttributes, and it confirms
    that one can set these three event masks simultaneously for two clients.

Perhaps you are confused by the wording, perhaps your server has a bug.
All three can be simultaneously set; the restriction is that two distinct
clients cannot simultaneously select for the same bit.  If you think there
is a bug in the MIT R4 server, please submit a bug report along with a small
test program.

    CopyGC
    Expected BadValue, Got Nothing
    A client makes a CopyGC request with an undefined bit in the ValueMask

A server bug, not a protocol bug.

    ClearArea, CopyArea, CopyPlane, PutImage
    Expected BadValue, Got Nothing
    These requests are made with rectangles containing negative
    values or very large values for x,y

No bug here.  All values passed at the protocol level are legal for rectangles.
The server should clip.

    SetScreenSaver
    Expected BadValue, Got Nothing
    Various disallowed values do not generate BadValue

Then your server has a bug.  (The R4 server generates BadMatch, which is
also wrong.)

    AllocColorCells
    Expected BadValue, Got Nothing
    Various disallowed values do not generate BadValue:
    colors=0, planes=-1

Server bug for colors=0.  Planes at the protocol level is CARD16, so
negative numbers are not possible (hence the nonnegative restriction
given in the protocol is redundant).

    AllocColorPlanes
    Expected BadValue, Got Nothing
    Various disallowed values do not generate BadValue:
    colors=0 red=-1 green=-1 blue=-1

Server bug for colors=0.  Red/green/blue at the protocol level are CARD16, so
negative numbers are not possible (hence the nonnegative restriction given in
the protocol is redundant).

    FreeColors
    Expected BadAccess, Got Nothing
    Attempt to free a color on a Static VisualType

It is not an error to free a cell that you have actually allocated.  If
you attempted to free a cell that you had not allocated, then your server
has a bug.  If you believe this is the case with an MIT R4 server, please
submit a bug report with a small test program.