identified and reported by Marcel Hendrix,
expressions of this kind could trigger a segmentation violation.
PTdifferentiate() roughly evaluates to
ternary_fcn(ge0(0-expr), 0, PTdifferentate(expr))
and mkb() optimizes
0 - expr --> unary_minus(expr)
IFeval() invokes PTeval() for the derivative too,
PTeval() looks at the incorrect tree->funcnum
and tries to PTeval for a second argument which is not there,
(unary_minus does not have a second argument)
causing a segmentation fault.
reported by Andy Fierman on the ngspice-users mailing list in message
"Help to identify 'parameter value out of range or the wrong type' error please?"
Their presence breaks automake rules when running
in a separate build directory.
And when regenerated cause unwanted "changed files"
in the repository.
As a consequence visual C compilation will fail.
It will still work with a "make dist" generated tar ball.
We need to upgrade the visual C project files
to invoke bison and flex on windows,
or we have to provide these generated files
in a visual C specific directory. (very annoying of course)
INPgetU2Tok() was introduced in commit
Date: Fri Sep 3 12:51:42 2010 +0000
bug in B source parsing removed
and later unused in commit
Date: Thu Apr 28 19:27:45 2011 +0000
bug fix, (#329233)
commit "memory leaks: code improved"
Date: Sun Apr 5 08:57:55 2009 +0000
'point' has not been incremented for so called
"Weird items" with string length == 1
In the B language this can be considered a bug fix.
In the .control language this is a severe change
and breaks backwards compatibility.
In all three languages 'numparam' 'B' and '.control' we now have
ln to the base e
log to the base e
log10 to the base 10
Thus log and log10 is now consistent
with the vast majority of programming languages.
ln is merely for convenience.
very few other languages have it.
I'd like to discourage its usage.
rlar
Francesco Lannutti
h_vogt
dwarning