Structure problem/question in NMODL

[mctavish]

I am trying to make a linked list in NMODL. I have the following structure and procedure in my mod file:

Code: Select all

VERBATIM
// Linked list of adjacent ARTCELL objects that this ARTCELL connects to.
typedef struct ADJ {
	double	id;		// ID of the adjacent ARTCELL
	void * nc;	// NetCon to the adjacent ARTCELL (even though it is a void*)
	struct ADJ *next;
} Adj;
ENDVERBATIM

PROCEDURE addAdjacentSection() {
VERBATIM {
    if (ifarg(2)) {  // id and nc object passed in from hoc
        Object *o = *hoc_objgetarg(2);
        check_obj_type(o, "NetCon");	
        Adj* adj = (Adj*)hoc_Emalloc(sizeof(Adj)); hoc_malchk();
        adj->nc=o->u.this_pointer;
        adj->id= *getarg(1);	// Id
        adj->next=NULL;
        printf("adj->id first=%f\n",adj->id);
        printf("adj->id second=%f\n",adj->id);
    }
}
ENDVERBATIM
}

Calling addAdjacentSection(1,nc) gives
adj->id first=1.000000
adj->id second=1.000000
which is exactly as it should do.

If I reverse the assignment to the instance of my structure, however, such that the id field gets filled before the nc field:

Code: Select all

        adj->id= *getarg(1);	// Id
        adj->nc=o->u.this_pointer;

then I get:
adj->id first=1.000000
adj->id second=0.000000

What is happening in this case to my field assignment between the two calls to printf() that is clobbering my initial assignment, and how can I be sure that having it the first way, which apparently works for my ID field is not clobbering something in my NC field?

[hines]

is getarg declared double anywhere in the mod file or in a file you are including?

As an aside, do you hjave a good reason for id to be a double and not int?

[hines]

Sorry, should have said, "double*".

[mctavish]

I figured it out.

I have a RANGE variable in MyArtCell called "id", as well as an "id" field in the structure in myartcell.mod. The resulting c file has a statement

Code: Select all

#define id _p[2]

which was throwing things off -- exactly how, I'm not sure, but changing the RANGE variable to "thisID" seems to be an appropriate fix for now.