Create 2 files, the first is from the manual section 14.7.2.1 page 499: ****** jfet1.cir ****** *Two-dimensional Junction Field-Effect Transistor (JFET) VDD 1 0 0.5V VGG 2 0 -1.0v AC 1V VSS 3 0 0.0V QJ1 1 2 3 M_NJF AREA=1 SAVE .MODEL M_NJF NBJT LEVEL=2 + options jfet defw=10.0um + output rootfile="./j1root/" psi n.conc p.conc phin phip equ.psi vac.psi + x.mesh w=0.2 h.e=0.001 r=1.8 + x.mesh w=0.8 h.s=0.001 h.m=0.1 r=2.0 + x.mesh w=0.8 h.e=0.001 h.m=0.1 r=2.0 + x.mesh w=0.2 h.s=0.001 r=1.8 + y.mesh...
to clarify the initial report: c4e2e82d42 src/circuit/inpgstr.c (arno 2000-05-25 20:25:40 +0000 40) /* now find all good characters */ c4e2e82d42 src/circuit/inpgstr.c (arno 2000-05-25 20:25:40 +0000 41) for (point = *line; *point != '\0'; point++) { c4e2e82d42 src/circuit/inpgstr.c (arno 2000-05-25 20:25:40 +0000 42) if ((*point == ' ') || c4e2e82d42 src/circuit/inpgstr.c (arno 2000-05-25 20:25:40 +0000 43) (*point == '\t') || c4e2e82d42 src/circuit/inpgstr.c (arno 2000-05-25 20:25:40 +0000 44)...
to clarify the initial report: c4e2e82d42 src/circuit/inpgstr.c (arno 2000-05-25 20:25:40 +0000 40) /* now find all good characters */ c4e2e82d42 src/circuit/inpgstr.c (arno 2000-05-25 20:25:40 +0000 41) for (point = *line; *point != '\0'; point++) { 5fdea34222 src/spicelib/parser/inpgstr.c (Chat GPT 2026-09-17 09:09:25 -0400 42) if (separator ? (*point == separator) : 5fdea34222 src/spicelib/parser/inpgstr.c (Chat GPT 2026-09-17 09:09:25 -0400 43) ((*point == ' ') || (*point == '\t') || (*point...
My local patch is how I found it. I do not yet have test cases for rootfile and IC.FILE. but the test cases are articulated above.... x=" " to become the empty string both x="fast" and x="fast mode" to become "fast" foo="fast,debug" to become foo=fast and debug Most importantly, as I tried to say above - I dont have the historical knowledge to know if INPgetStr was designed on purpose to act so weirdly! If someone, with historical knowlege could answer that, then I can write test cases, and submit...
My local patch is how I found it. I do not yet have test cases for rootfile and IC.FILE. but the test cases are articulated above.... x=" " to become the empty string both x="fast" and x="fast mode" to become "fast" foo="fast,debug" to become foo=fast and debug Most importantly, as I tried to say above - I dont have the historical knowledge to know if INPgetStr was designed on purpose to act so weirdly! If someone, with historical knowege could answer that, then I can write test cases, and submit...
the current behavior seems to conflict the examples in the manual. But each of those examples seems to bypass INPgetStr. But CIDER rootfile and IC.FILE examples would go through INPgetStr and filenames with offending characters will cause issues.
Note: the test suite does not seem to have coverage for this and both patches do not change the test outcomes.
is inpgstr.c INPgetStr faulty?