Under VMS V6.0, and under previous versions of VMS with CSC Patch 1053
applied, DEC made a change that causes many client-side implementations
to crash: What follows is part of a dialog a coworker had with DEC earlier,
troubleshooting a similar problem elsewhere.

>The 1053 patch changed the keycode range to align correctly with x protocol. 
>The motif toolkit (not the server) now has a problem.  Digitals version of the
>toolkit has fixed the problem in motif 1.1 for the client side.  We think that
>sun has also fixed the problem in its latest version of motif.  This is a
>client side osf motif bug that cropped up when we complied with x protocol in
>the 1053 patch.
>
>        The actual change in CSCPAT_1053 that causes the problem:
>
>          1. The server internally hardcodes a range of supported
>             keycodes from keycode 86 to keycode 251.  However,
>             according to the X protocol, the range should be between
>             8 and 255.
>
>Increasing the maximum keycode to 255 causes an overflow in a loop counter
>that eventually causes an access violation.

This causes a problem with the following section of Motif code:

void XtKeysymToKeycodeList(dpy, keysym, keycodes_return, keycount_return)

Display *dpy;
KeySym keysym;
KeyCode **keycodes_return;
Cardinal *keycount_return;
{
register XtPerDisplay pd = _XtGetPerDisplay(dpy);
register XtPerDisplay pd = ((_XtperDisplayList->dpy == (dpy))
      ? &_XtperDisplayList->perDpy      : _XtSortPerDisplayList(dpy));
KeyCode keycode;
int per, match;
register KeySym *syms;
register int i, j;

...

per = pd->keysyms_per_keycode;
for (syms = pd->keysyms, keycode = pd->min_keycode;
    keycode <= pd->max_keycode;
    syms += per, keycode++)
{
    match = 0;
    for (j = 0; j < per; j++)
    {
    /* access violation occurs here. 
        Syms is a pointer and in Digitals MOTIF 1.0a "keycode" has only a
        byte of storage.  Everytime through this above loop we check to
        see if "keycode" is less than or equal to the max_keycode, if true
        move the pointer("syms") and add one to "keycode". Since 1053
        raises the max_keycode(pd->max_keycode) to 255, and "keycode"
        is only a byte, when keycode reaches 255 adding one would result
        in an overflow("keycode" set back to zero), thus never being
        greater than max_keycode(255).  As the loop continue the
        pointer("syms") steps through memory until it hits a page it can
        not read, thus resulting in an access violation.
    */
        if (syms[j] == keysym)
        {
            match = 1;
            break;
        }
...



I'd like any ideas as to how to avoid this code from being used, which I
imagine could possibly be done by not setting up keypress event handlers and so
forth. I'm not quite sure what all would have to be disabled though to work
around this problem. My first attempt was to modify GUI.C by placing

    #ifndef IGNORE_KEY_HANDLING
    ...
    #endif

around sections of code that I felt would tickle this behaviour, i.e. the
XmAddEventHandler()'s specifying KeyPressMask, and the event handler itself.
That hasn't quite caught everything yet, and I'm afraid I'll make the program
useless by the time I disable enough features to bypass this bug!

Anyway, I thought I'd let you folks know what I've found, so you could pass it
on to anybody else encountering the same problem. I'll keep working on a
work-around for myself (I have to use the Ultrix box and display on the VAX
because the ultrix box is a 'firewall' system, and the VAX is on my desk).
<h6>From Cache (local 50 hours old.)</h6>