From: Giles A. <ga...@bt...> - 2020-12-06 21:01:45
|
I found two plausible bugs with options (.option cards). Bug 1: Unrecognised options are silently ignored. That seems unhelpful. But if I add reporting in if_option() (ifspice.c), several unexpected errors are reported: ga@oldell:~/ngspice-33$ release/src/ngspice test.cir Warning: unknown option rndseed. Warning: unknown option history. Warning: unknown option oscompiled. Warning: unknown option program. Warning: unknown option prompt. Warning: unknown option noglob. Warning: unknown option brief. Warning: unknown option sourcepath. Warning: unknown option inputdir. Warning: unknown option x11lineararcs. Warning: unknown option interactive. Warning: unknown option stepsizelimit. Warning: unknown option __flag. Warning: unknown option __flag. Warning: unknown option inputdir. Warning: unknown option ngbehavior. Warning: unknown option svgwidth. ****** ** ngspice-33 : Circuit level simulation program ** The U. C. Berkeley CAD Group ** Copyright 1985-1994, Regents of the University of California. ** Copyright 2001-2020, The ngspice team. ** Please get your ngspice manual from http://ngspice.sourceforge.net/docs.html ** Please file your bug-reports at http://ngspice.sourceforge.net/bugrep.html ** Creation Date: Wed Dec 2 17:07:28 UTC 2020 ****** Warning: unknown option inputdir. Circuit: test pspice parsing ngspice 844 -> run Warning: unknown option sim_status. Doing analysis at TEMP = 27.000000 and TNOM = 27.000000 Initial Transient Solution -------------------------- Node Voltage ---- ------- No. of Data Rows : 59 ngspice 845 -> None of those "unknown option" messages come from the circuit file, and two come from .spiceinit. The names look like C-shell variables, and I find that I can examine ".option" values interactively with 'echo'. So it seems that shell variables mirror options, and can set them. Indeed, I get: ngspice 861 -> set var=val Warning: unknown option var. ngspice 862 -> I did not see that in the manual, but the book is big. After searching, perhaps the second sentence of 17.7 hints at this. To me, having shell variables change options of the same name is a bug (Bug 2). At least it is contrary to "The Principle of Least Astonishment", and I can see it driving mad a person who innocently uses an option name for a script variable. And there is already a dedicated shell command, "option", for setting the options. But fixing it now may cause problems to existing users. It seems that the new messages occur when cp_vset() (variable.c) calls cp_usrset() (options.c). My guess is that the right fix for Bug 1 would be to add an argument to if_option() so that it knows when it is called from C-shell, and can suppress the message. The best fix for Bug 2 might be to add a warning whenever a variable assignment successfully changes an option, recommending the "option" command. Then, after a few releases, remove the behaviour. Also, it seems that option cards are removed from the deck and parsed early, in (frontend/inp.c). Does that mean that INPdoOpts() in src/spicelib/parser/inpdoopt.c can never be called, and should be removed? |