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.
We may now use the following sequence for a file
search from a code model:
Infile_Path/<infile>
NGSPICE_INPUT_DIR/<infile>, where the path is given by the environmental variable
<infile>, where the path is the current directory
avoid copy of parameter array,
which would need to be freed to avoid a memory leak
this is a modified and partial version of a patch provided by
Krzysztof Blaszkowski <kb@sysmikro.com.pl>
rlar
h_vogt
dwarning