Path: utzoo!attcan!uunet!husc6!bloom-beacon!apple!rutgers!ucsd!ucbvax!hplabs!hp-pcd!hpcvlx!fred From: fred@hpcvlx.HP.COM (Fred Taft) Newsgroups: comp.windows.x Subject: Re: HP's Xtk Bug Fixes Message-ID: <1610041@hpcvlx.HP.COM> Date: 15 Aug 88 18:13:38 GMT References: <1610032@hpcvlx.HP.COM> Organization: Hewlett-Packard Co., Corvallis, OR, USA Lines: 105 ### bug number: 402 ### area: Xt ### severity: medium ### comments: VERSION: Xtk release 2 SYNOPSIS: XtGetValues() returns bogus information on 68000 architecture machines, if the application queries a short or char value, and it also specifies within the arglist a pointer to a short or char variable, into which the result is to be placed. DESCRIPTION: Several months ago, I reported a discrepancy in how XtGetValues() worked, versus how it was documented. I received a message that the problem was being fixed, yet I notice that it is still present in the R2 toolkit, to a degree anyways. According to the documentation, when you issue a GetValue request, you pass in an arglist composed of an argument name/address pair; the address indicates where the return value should be placed. If I don't supply a pointer (i.e. I pass in a NULL address), when I query a Boolean value, the value is always returned in the arglist; I noticed that CopyToArg() specifically tested for this case; I can live with this, since it allows old clients to continue to run. However, if I do pass in an address, then the returned boolean value was always 0 (FALSE). After further investigation, I believe the problem lies in the following line of code which had been added to CopyToArg() to fix the original problem: if (*dst != NULL) dst = *(XtArgVal **)dst; The above statement treats everything as a pointer to a long variable; XtArgVal is typedef'ed to a long. In the days where the values were always returned in the arglist, treating the destination as a long was fine since the value field really was a long. However, since the value now pointed to by dst can be a char, a short, a long, etc, this assumption is no longer valid. For instance, assume the following: dst ----> arglist value entry ----> a boolean variable ("---->" denotes 'pointing to') When the buggy statement shown above is executed, the picture now looks like the following: dst ----> a boolean variable Since the argument being queried is a char, the following is used to copy the value into the specified destinatioin: *dst = (XtArgVal) *((char *) src); Since the value pointed to by dst is assumed to be a long, the following four bytes are copied into the location we specified: 0x00, 0x00, 0x00, 0x01 Unfortunately, at least for those of us using 68000 architecture, the first 0x00 is copied into our destination, instead of the 0x01. REPEAT-BY: Boolean flag; Arg arg[1]; XtSetArg (arg[0], XtNsensitive, &flag); XtGetValues (w, arg, XtNumber(arg)); FIX: /* Patch to Resources.c */ 64a65,66 > Boolean addrGiven = False; > 66a69 > { 67a71,72 > addrGiven = True; > } 72c77,82 < *dst = (XtArgVal) *((short *) src); --- > { > if (addrGiven) > *((short *)dst) = (short)*((short *) src); > else > *dst = (XtArgVal) *((short *) src); > } 74c84,89 < *dst = (XtArgVal) *((char *) src); --- > { > if (addrGiven) > *((char *)dst) = (char)*((char *) src); > else > *dst = (XtArgVal) *((char *) src); > }