modnames was restored on regular returns.
it was not restored on error returns.
consider this a bug.
if we assume it was saved for error returns as well,
then modnames need not be passed by reference,
and the unreferenced variant need not be restored.
we see now more clearly,
that a wl_free of the locally prepended new elements
to modnames should be freed on return.
lives in
inp_subcktexpand() where it is used and passed to doit()
doit()
where it is (read only) used, and passed to doit() modtranslate() and translate()
does a strance protect,
translate()
where it not used, but passed to numnodes()
numnodes()
where it is used read-only
modtranslate()
where it is used to insert at the front
submod0 is only aceesd in doit,
always set NULL on entry,
(almost) always restored on return
was not restored on error ...
fixme check this changed behaviour
doit()
uses this list, and executes modtranslate() and devmodtranslate()
modtranslate()
uses submod, to prepend to the list
devmodtranslate()
just traverses the list
nobody looks at subs0, except doit().
doit() allways initializes it to NULL,
and restores it on return
thus its a local ...
note:
in error cases subs is *not* allways restored
assume this to have been a bug
in response to the `ex-41.cir' test case
distilled from a Dietmar Warning Bug report in
"Subject: Re: subckt, param"
translate() is called recursively and depends on
`num of nodes' provided by numnodes().
numnodes() depends on availability of `su_numargs'.
But the processing allows non-processing of subckt instantiations
in inner recursions (which will be processed later)
which means `su_numargs' is not always available.
Simon Guan reported
Bug item #3509528, `Meas goes wrong when put in a while loop'
In a .control block a `let' variable was passed to the `measure' command.
The value of this variable would have been a plain integer,
yet it was converted internally to an internal ascii representation
with exponential representation (203 ==> 2.03e2)
and then processed by `ft_numparse()' where it was converted back to
double floating point.
Because the intermediate 2.03 has
no exact representation in the space of double floating point numbers
this conversion was lossy and resulted in a non-integer value.
This non-integer was then truncated towards minus infinity in com_measure
yielding an error of -1
This commit implements round to nearest in com_measure2
to avoid the problem.
FIXME,
the internal intermediate conversion of double floating point machine
values to ascii representations must be dropped,
or replaced with an exact/lossless ascii representation.
(for example GNU printf/scanf %a or 64bit hexadecimal representation)
rlar
h_vogt