loop over DEVmodDelete() and DEVdelete() in CKTdestroy()
instead of doing this business in the DEVdestroy() functions.
As a consequence, most DEVdestroy() functions
collapse completely.
Instead of searching and then deleting a given device-model,
just delete the given model.
The search shall be done somewhere else.
Don't free the model struct itself,
this shall be done by the invoker himself.
Don't free the device instrance list,
this shall be done by the invoker himself.
As a consequence, most DEVmodDelete() functions
collapse almost completely.
This change is of no consequence,
because DEVmodDelete() is currently nowhere used.
Instead of searching and then deleting a given device-instance,
just delete the given instance.
The search shall be done somewhere else.
Don't free the instance struct itself,
this shall be done by the invoker.
As a consequence most DEVdelete() functions
collapse almost completely.
This change is of no consequence,
because DEVdelete() is currently nowhere used.
MIFdelete() might be called with third arg being NULL,
searching for the instance to be deleted by name only.
Need to invoke the callback in this case too.
which silently dropped the
here->initialized = MIF_FALSE
aspect of the MIFunsetup() function
which caused segfault in testcase
examples/memristor/memristor_x.sp
Allow to register a callback function in the cfunc.mod files,
which will be invoked in MIFdestroy.
Usefull to "free" memory which has been allocated locally in a cfunc.mod file.
Fixme, this code is simply broken,
nobody seems to use it.
One would need to change the socket protocol (message length)
in agreement with the users of the protocol.
For the time beeing,
just suffocate the warnings in a way which does not change
the broken behaviour of this code.
Thats a workaround for a segmentation fault (buffer overrun)
caused by too long lines in the input file for a xspice "d_source"
Thanks to Siddhant Saraf, who reported this in
#301 d_source gives wrong error and then SIGSEGV (Address boundary error)
http://sourceforge.net/p/ngspice/bugs/301/
notably on debian gnu/linux with package `mingw-w64'
cross-compile a mingw 32bit windows executable with this incantation:
(compile "
./autogen.sh
rm -rf tmp-build tmp-output
mkdir -p tmp-build tmp-output
( cd tmp-build && ../configure \
--build=$(../config.guess) \
--host=i686-w64-mingw32 \
--prefix='c:/spice' \
--exec-prefix='c:/spice'\
--with-windows --enable-xspice --enable-cider --disable-debug )
LC_ALL=C make -C tmp-build -k -j6
LC_ALL=C make -C tmp-build -k -j6 DESTDIR=$(pwd)/tmp-output/ install
(cd 'tmp-output/c:/' && zip -r - .) > tmp-output.zip
")
compilation to Win64 works the same way, with
--host=x86_64-w64-mingw32
The tmp-output.zip directory structure resembles the
structure of our original sourceforge ngspice-26_140112.zip windows package
ready to be unzip'ed in c:/
Though the testfiles, examples and documentation is missing.
Holger Vogt
rlar
Tim Edwards
h_vogt
mhx