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
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.
for almost all other external nodes (notable exception "txl")
src/spicelib/devices/*/*def*.h, declare external node variables const
1) The compiler shall emit an error message if we still mess around
with external node numbers.
2) To mark which elements of the instance struct are meant to be set
externally when parsing the netlist
These "external" node variables are exclusively set via the
overlay struct GENinstance, member GENnode[]
We shall not mess around with these "external" node variables
because it would get rather difficult to avoid bugs considering
re-invocation of the XXXsetup() routine.
This gets interesting for devices with optional ports,
which get copied around depending on the amount of connected ports.
rlar
h_vogt
Tim Edwards
dwarning