initialise param_beg and param_end before they will be used,
instead of "afterwards" in preparation for the next following usage.
and move the "comment out" up some lines, think that way:
comment out original line, append new line, ...
Traversing all linked memory structures to free their memory
can be a somewhat lengthy business, especially in xspice,
which is not worth the effort when we simply want to exit()
Long delays have been reported in certain cases.
For developers and for the usage of such tools as valgrind,
we still free all the memory if 'set ngdebug' is given.
which silently dropped the
here->initialized = MIF_FALSE
aspect of the MIFunsetup() function
which caused segfault in testcase
examples/memristor/memristor_x.sp
which have been invalidated by commit:
ifparm, #4/16, missing IF_REDUNDANT for some aliases, introduce IOPAPR
before this commit, sensitivity to "capacitance" was published twice,
once with name "c1" (reference name of a CAP device)
and as "c1_c" (reference name of a CAP concatenated with param name "c")
after said commit, sensitivity is no longer published as "c1_c"
(because "c" is only an "alias"/IF_REDUNDANT of the main parameter
which is named "capacitance", and "capacitance" is a IF_PRINCIPAL
and thus avoids "concatenation" of the parameter name)
and use a more robust test for local node numbers.
That is, transform this pattern :
if (here->Node && ...) {
CKTdltNNum(ckt, here->Node);
here->Node = 0;
}
into this :
if (here->Node > 0 && ...)
CKTdltNNum(ckt, here->Node);
here->Node = 0;
The change of "!= 0" ==> "> 0" accounts for rare cases where "Node"
might have been set to -1, (meaning "unconnected")
The unconditional execution of the zero assignment is for those cases
where "Node" might have been assigned to some external or other local Node.
If so, the variable would not be set to zero, confusing the "guarding" if's
in the corresponding XXXsetup() routine.
The Pattern to follow is:
1) unset and delete *all* local Nodes in XXXunsetup()
2) allocate all of them again in a re-invocation of XXXsetup(),
exactly the same way as in the very first invocation.