Experimental Physics and
Industrial Control System

"Redman, Russell O." <[email protected]> · Tue, 12 Jun 2001 14:40:00 -0700

I believe I have found a bug in e2db.  In edifRead.c, in "int readcell(FILE
*file)",
new (struct cell)'s are constructed using the code

	if (!chead)
		chead = curcel = (struct cell *)malloc(sizeof (struct
cell));
	else
		{
		curcel->flink = (struct cell *)malloc(sizeof (struct cell));
		curcel = curcel->flink;
		}
	curcel->polink = (struct port *)NULL;
	curcel->prlink = (struct prop *)NULL;
	curcel->ilink = (struct instance *)NULL;
	curcel->nlink = (struct net *)NULL;

Later in the program the list of cells is traversed using code like
	for (cptr = chead; cptr != 0; cptr = cptr->flink) {...}

The problem is that flink is not being initialised.  The last cell in the
list will contain an uninitialised flink pointer that may accidentally be
filled with 0, but may point to any random location in memory, causing the
program to crash when an attempt is made to access the contents of the bogus
cell.

The solution is simply to initialise flink:
	if (!chead)
		chead = curcel = (struct cell *)malloc(sizeof (struct
cell));
	else
		{
		curcel->flink = (struct cell *)malloc(sizeof (struct cell));
		curcel = curcel->flink;
		}
	/* The flink field was not being initialized. It should be set to 
           (struct cell *)NULL so that traversing the chead tree is 
            guaranteed to terminate. R. O. Redman, 2001-06-12 */
	curcel->flink = (struct cell *)NULL;
	curcel->polink = (struct port *)NULL;
	curcel->prlink = (struct prop *)NULL;
	curcel->ilink = (struct instance *)NULL;
	curcel->nlink = (struct net *)NULL;

With this change the program seems to run (more) correctly.

There is a stylistic issue in that the for loop tests for the completion of
the loop using "flink != 0", instead of "flink != NULL".  Practically, they
are the same test but since pointers are (or should be) initialised to NULL,
they should also be tested against NULL.  This stylistic defect occurs in a
variety of places throughout the program.

I believe there is still another problem hidden somewhere in the code.
Quite routinely, when I make an error in the definition of the properties of
a record in my CapFast diagrams, the record is silently deleted from the
database.  I believe the critical step is again e2db because the offending
records are present in the .edf file, but are missing in the .db file.  No
error or warning mesages are issued.  I have not yet been able to identify
which errors cause this behaviour, but I consider it a serious defect that
records can be dropped from the database without some error or warning
message being issued.

In a related issue, I normally place frames around all my CapFast diagrams.
These result in entries like the following in the .edf file:
          (instance (rename frame "frame")
            (viewRef NETLIST_VIEW
              (cellRef bb200tr)))
Unfortunately, e2db tries to find the cell "bb200tr" that is being
referenced, and issues a lot of messages like
	FATAL: Cannot find cell "bb200tr" in EDIF file.
In fact, this is not a fatal error because the missing "cell" is not
connected to anything, and e2db normally proceeds to produce a valid
database.  It would be more appropriate for e2db to recognise that a frame
has no connections and can be ignored (unlike the real records).

Russell O. Redman

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System