[comp.windows.x] Xt realloc

rlkd@opusys.UUCP (R.L.K.Dattatri) (06/20/89)

Problem of calloc() and realloc() with zero size arguments:

The Xt (X Toolkit) routines seem to be calling memory allocation 
routines (realloc() and calloc()) with a request of zero bytes.
If the library does not accept such requests and returns a NULL
value, then I get an error messgae 
	"X Toolkit Error; cannot perfom calloc'.

The problem seems to be in the file TMstate.c in lib/Xt.
The routine _XTOverrideTranslations() calls MergeTables.

void _XtOverrideTranslations(old, new,merged)
    XtTranslations old, new,*merged;
{
    XtTranslations temp;
    if (old == NULL) {
	*merged = new;
	return;
    }
    _XtInitializeStateTable(&temp);
    temp->clickTime = new->clickTime;
    /* merge in new table, overriding any existing bindings from old */
    MergeTables(temp, new, FALSE,new->accProcTbl);
    MergeTables(temp, old, FALSE,old->accProcTbl);
    *merged= temp;
}

 
THIS PART IS FROM MergeTables()

1    for (i=0,j=old->accNumQuarks; i < new->accNumQuarks; ) {
2        if (j == old->accQuarkTblSize) {
3            old->accQuarkTblSize += 20;
4            old->accQuarkTable = (XrmQuark*) XtRealloc(
5                (char *)old->accQuarkTable,
6                old->accQuarkTblSize*sizeof(int));
7         }
8         old->accQuarkTable[j]=new->accQuarkTable[i];
9         old->accNumQuarks++;
10        accQuarkIndexMap[i++] = j++;
11   }
/* merge accelerator action bindings */
12   if (old->accProcTbl == NULL) {
13       old->accProcTbl = (XtBoundAccActionRec*)XtCalloc(
14           old->accQuarkTblSize,sizeof(XtBoundAccActionRec) );
15   }
16   else {
17	old->accProcTbl = (XtBoundAccActionRec*)XtRealloc(
18       (char *)old->accProcTbl,
19	old->accQuarkTblSize*sizeof(XtBoundAccActionRec) );
20    }
21
22    for (i=0/*,k=k*/;i<new->accNumQuarks;){
23        old->accProcTbl[k].widget = accProcTbl[i].widget;
24        old->accProcTbl[k++].proc = accProcTbl[i++].proc;
25    }
26
27    for (i=0; i < new->numEvents; i++)
28	MergeStates(
29	    &old->eventObjTbl[indexMap[i]].state,
30	    new->eventObjTbl[i].state,
31	    override,
32	    indexMap,quarkIndexMap,accQuarkIndexMap,
33	    old,
34	    (StateMap) NULL);
35   XtFree((char *)indexMap);
36   XtFree((char *)quarkIndexMap);
37   XtFree((char *)accQuarkIndexMap);

The Problem:

If at line 1, the value of old->accNumQuarks==0, and new->accNumQuarks==0,
the inner 'if'  (line 2) is not executed and hence the element 
accQuarkTblSize==0.

When this happens, the calls to XtCalloc() or XtRealloc() end up with
arguments of zero. (lines 13 and 17 respectively)

The Question:

Does X expect the memory allocation routines to care of 'zero' bytes request?
Is this some kind of bug in the ToolKit.?

As of now, I have fixed this with a request=1 whenever a zero is passed
as an argument.
ANSI C does not specify any hard and fast rule for zero bytes request; 
(it is implementation defined!)

HAS ANYONE SEEN THIS PROBLEM? ANY SOLUTIONS FOR THIS?

|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| R.L.K. Dattatri           (408) 446-2110 (W)     |~~~~~|                 |
| Opus Systems              (408) 243-5140 (H)     |_____|                 |
| 20863 Bldg 400                                   |\   |   |/ |~~\        |
| Stevens Creek, Cupertino                         |  \ [___|\ |   |       |
| California, 95014                                     \      |   |       |
| E-mail: uunet!opusys!rlkd  FAX: (408) 446-5009          \    |__/        |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

swick@ATHENA.MIT.EDU (Ralph R. Swick) (06/30/89)

> Does X expect the memory allocation routines to care of 'zero' bytes request?

The MIT implementation does not necessarily expect malloc(0) to behave
the same on all systems.

> Is this some kind of bug in the ToolKit.?

Yes, and we plan to fix it in the same way that Xlib handles it; by
adding a configuration parameter (actually, using the one that's
already there for Xlib) to tell Xt how the particular libc behaves.