Find a segmentin the tree

PNode find( PNode n, PNode  r, int tag,Action *a) {
if(n) {
if(n->less && (n->ptr > (r->ptr + r->size)) )
find(n->less,r,less_tag,a);
if(n->more && ((n->ptr + n->size )< r->ptr)) )
find(n->more,r,more_tag,a);
}
if(n) a(n,r,tag);// Matched
return(n);
}

 Simple enough. When the current node  identifies an overlapping segment, the the segment is found and an action is taken.  I the action is delete, the delete action first attempts a merge, combining adjacent segments, on the tree

Note. I can pack a segment identifier as two int in a long, then directly use long greater than and less than to discover overlap. But that is bouncing the rubble.

Now, te nodes tht identify segments also have names and enter a symbol tree, not necessarily coherent with this.  But the segment node carries the plain text name for the segment.  If I keepthe name tree just as fast, all packed char, then I never point to symbols, or do much structure coordinating, I just look it up; code is simple, and if the steps are log2 on the set of names, I am fine. 256 different, eight char names is an eight step test and jump, worst case,  on 64 bits, I will take that any day on any compiler for the shear convenience of having name space at this lower level. And I can shorten it considerably using name space partitions inside my packed char to guide the path length.

So, in consent, it is all driven by plain text lookup, the segment,the network node names, the entry points; the way xchars does it.  The things names are tagged and pointed to.