Menu
▾
▴
gnuplot-beta
|
From: Taro S. <no...@gm...> - 2005-06-27 17:36:21
|
Hello. This is my first attempt at filing a potential bug report.=20 Please let me know if I'm doing something inappropriate here.=20 Especially if this is not a good place to do this, please point me to the right direction. I like the cvs version of gnuplot so much that I'd like to keep submitting if I find any bugs in future. It seems the gnuplot has difficulty distinguishing a user-defined function and a string file name stored in a variable. I have an ASCII data file "xy.dat" with the following content: BEGIN xy.dat------------------- 0 0 1.1 0.9 2.3 2.1 2.9 3.2 END---------------------- and wish to overplot a straight line. If I do BEGIN plot.okay.gp------------------- reset f(x) =3D x plot f(x), 'xy.dat' u 1:2 pause -1 END---------------------- The plot comes out fine, but if I store the data file name in a string as i= n BEGIN plot.nogood.gp------------------- reset f(x) =3D x fdat =3D 'xy.dat' plot f(x), fdat u 1:2 pause -1 END---------------------- then gnuplot complains: "plot.nogood.gp", line 4: warning: encountered a string when expecting a nu= mber "plot.nogood.gp", line 4: NB: you cannot plot a string-valued function Thanks for your time, Taro |
|
From:
<br...@ph...> - 2005-06-28 15:31:40
|
Taro Sato wrote:
> It seems the gnuplot has difficulty distinguishing a user-defined
> function and a string file name stored in a variable.
> reset
> f(x) = x
> fdat = 'xy.dat'
> plot f(x), fdat u 1:2
> pause -1
> "plot.nogood.gp", line 4: warning: encountered a string when expecting a number
> "plot.nogood.gp", line 4: NB: you cannot plot a string-valued function
This is not exactly a bug, but a known syntactical limitation. The way
around it is to drop the parser a hint that fdat is meant to be a
string, not a number, like this:
plot f(x), ''+fdat u 1:2 # or was that ''.fdat ?
Concatenating fdat with the empty string yields a string constant, and
the parser seeing the "'" that start off this entry in the command line
can directly deduce that this is not a number, but a string.
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2005-06-28 16:06:35
|
On Tuesday 28 June 2005 08:34 am, Hans-Bernhard Br=F6ker wrote: > Taro Sato wrote: > > > > f(x) =3D x > > fdat =3D 'xy.dat' > > plot f(x), fdat u 1:2 > > "plot.nogood.gp", line 4: warning: encountered a string when expecting > > a number "plot.nogood.gp", line 4: NB: you cannot plot a string-valued > > function > > This is not exactly a bug, but a known syntactical limitation. The way > around it is to drop the parser a hint that fdat is meant to be a > string, not a number, like this: > > plot f(x), ''+fdat u 1:2 # or was that ''.fdat ? The string concatenation operator is . so the hint would be ''.fdat However, I think this really is a bug. `plot f(x)` and `plot fdat` both work individually; it is only the combination of the two that triggers an error message. That should be fixable. I suspect that whatever causes this will also turn out to explain a problem in one of Juer= gen Wieferink's patches. The difficult case (which this is not an example of) is distinguishing a user-defined function that returns the name of a file from a user- defined function that returns a numerical value. =2D-=20 Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From:
<br...@ph...> - 2005-06-28 17:28:37
|
Ethan A Merritt wrote:
> The difficult case (which this is not an example of) is
> distinguishing a user-defined function that returns the name of a
> file from a user- defined function that returns a numerical value.
We may be closer to that case than you realize.
plot fdat
could be a plot of a file (if fdat is a string-valued variable), a
linear function (if 'set dummy fdat' is in effect), or a constant (if
fdat is a numerical variable). There are four cases, distinguished by
the attribute pairs string<-->numeric and literal<-->expression.
There is not actually a distinction between function and expression to
be made here. I.e. the 'plot' command line parser is not trying to find
a function --- it's trying to find an expression that it can evaluate,
and a simple variable or even a literal fit that bill nicely. That's why
all of
plot 5
plot a
plot x
plot 5*a+f(x)
work. To recognize that a file name is being input, the parser needs
some way of figuring out that what the type of a given expression is.
Before string variables, that was simple: strings could only be
literals, and those were easy to recognize by the opening ' or ". Now
it's trickier, and in the example discussed here, it fails.
In the case of a 'plot fdat', there's no syntactic hint at all --- you
have to actually check the type of fdat to see if this is a filename or
a numeric variable. I.e. the exact same plot command line could produce
a function or a data plot, at different times in the same gnuplot session.
|
|
From: Ethan M. <merritt@u.washington.edu> - 2005-06-28 18:15:30
|
On Tuesday 28 June 2005 10:31 am, Hans-Bernhard Br=F6ker wrote:
>=20
> To recognize that a file name is being input, the parser needs=20
> some way of figuring out that what the type of a given expression is.=20
> Before string variables, that was simple: strings could only be=20
> literals, and those were easy to recognize by the opening ' or ". Now=20
> it's trickier, and in the example discussed here, it fails.
Right. It used to be sufficient to do "if (isstring(c_token))".
Now it is necessary to check
"if (isstring(c_token) || isstringvar(c_token) || isstringfunc(c_token)=
)"
The problem is we don't *have* a function isstringfunc().
We do have the first two, and they are properly used in many places.
But the loop-over-functions in plot2d.c neglected the isstringvar() test.
I've corrected this and the equivalent place in plot3d.c, and will add
the bug-fix to cvs after it's been through the usual checks and testing.
=2D-=20
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
|
From:
<br...@ph...> - 2005-06-28 19:51:10
|
Ethan Merritt wrote: > Right. It used to be sufficient to do "if (isstring(c_token))". > Now it is necessary to check > "if (isstring(c_token) || isstringvar(c_token) || isstringfunc(c_token))" It shouldn't be that complex. IMHO, isstring() should have been renamed to isstringconst(), and a new isstring() been implemented that computes the above || expression. Then a single go through all the sources, replacing those (few?) uses of isstring() that actually have to be isstringconst(), would have sufficed to change the global behaviour. I.e. isstring() should have changed meaning from "token is a string literal" to "token starts a string-valued expression". > The problem is we don't *have* a function isstringfunc(). |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-06-28 20:03:20
|
On Tuesday 28 June 2005 12:54 pm, Hans-Bernhard Br=F6ker wrote: > IMHO, isstring() should have been renamed=20 > to isstringconst(), and a new isstring() been implemented that computes=20 > the above || expression. I will consolidate the (isstring() || isstringvar()) test into a single call isstringvalue(). This simplifies the code, which is good. If/when Juergen comes up with a fully working isstringfunc(), that can be added at a single point in isstringvalue(). =20 By my current count there are 14 of these consolidated tests,=20 as compareded to ~60 remaining instances of the original isstring(). So I agree with you in principle, but let's get the simplified code checked out first before considering a grand re-naming. =2D-=20 Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Juergen W. <wie...@fr...> - 2005-07-10 20:35:13
|
On Tuesday 28 June 2005, Ethan Merritt wrote:
> I will consolidate the (isstring() || isstringvar()) test into a single
> call isstringvalue(). This simplifies the code, which is good.
> If/when Juergen comes up with a fully working isstringfunc(), that can be
> added at a single point in isstringvalue().
I have uploaded a patch addressing the plot/splot problem [#1231847,
str_or_express-2005-07-09.patch]. As far as I can see, it works
sensible in almost all cases. The only known failure case is
gnuplot> x = "file"
gnuplot> f(x) = x . ".dat"
gnuplot> plot f(x)
where it assumes f(x) to be a function plot. But anyone careless
enough to use a dummy name in such a way ...
The second patch [#1231847, get_string-2005-07-09.patch] introduces
the function isexpr(). The idea is to provide a set of functions,
which do as many work as possible.
For example:
* get_string():
Read in string. If there is none, int_error().
Probably a more concise error message could be given from the
calling function.
* try_to_get_string()
Read in string if there is one. If there is none, no operation.
Implementation draft:
save_token = c_token;
result = NULL;
if (isexpr()) {
struct value a;
const_expr(&a);
if (a.type == STRING)
result = a.v.string_val;
else
c_token = save_token;
gpfree_string(&a);
}
* get_number()
* try_to_get_number()
* get_number_or_string():
Well, basically the same as const_expr() now.
* try_to_get_number_or_string()
The latter two functions would be easier to implement without the
GP_STRING_VARS conditionals. They can also be written similar to
str_or_express(), though.
In my opinion such functions should allow for some simplification to
the current code. What do you think? Is this worth going on?
Juergen
PS: I won't read my mails a week or so because I'm on holiday.
|
|
From: Juergen W. <wie...@fr...> - 2005-06-29 10:49:11
|
Ethan Merritt wrote: > I will consolidate the (isstring() || isstringvar()) test into a single > call isstringvalue(). This simplifies the code, which is good. > If/when Juergen comes up with a fully working isstringfunc(), that can be > added at a single point in isstringvalue(). This is tricky. The functions isstring() and isstringvar() only check the next token if it is/contains a string. The current syntax implies that the whole expression has to be a string then. A call to isstring() and isstringvar() is thus safe. A function isstringfunc() will have to evaluate the whole expression. This should only be tried if we know that the syntax requires an expression. Such a function must not be called if the next token can be a key word. An invalid expression would lead to an int_error(). Theoretically, this could be implemented. But it means that all command line parsing would have to check for key words *before* the call to isstringfunc() [or an extended isstring()]. All call sites in the sources would have to be checked and quite few would have to be rewritten if they were to use isstringfunc(). BTW: I wouldn't like to evaluate an expression and to throw away everything but the type of the result. The function try_to_get_string() seems more appropriate in the cases where isstringfunc() can be used. > By my current count there are 14 of these consolidated tests, > as compareded to ~60 remaining instances of the original isstring(). > > So I agree with you in principle, but let's get the simplified code > checked out first before considering a grand re-naming. Juergen |
|
From:
<br...@ph...> - 2005-06-29 12:07:24
|
Juergen Wieferink wrote: > A function isstringfunc() will have to evaluate the whole > expression. If so, that strongly suggests a serious design flaw to me. The expression evaluation engine didn't have a type system before the introduction of string-variables, because it didn't need one. Now we need one, but what you say there means we don't have it. It must be possible to find out an expression's result type without computing its actual value. If there's any ambiguity, force people to resolve it by using type-punning operators like real(), int() or string(), or equivalently by starting (sub-)expressions with ''. or 0+ > This should only be tried if we know that the syntax > requires an expression. Such a function must not be called if the > next token can be a key word. Then let's make sure we find all such cases early enough to change the syntax to require keywords wherever possible. > An invalid expression would lead to > an int_error(). This, however, seems deeply wrong. A simple parsing helper function has no business bailing out to the command line. If it were "parse_expression()", i.e. it was supposed to do something with the expression, that might be a different thing, but a mere test meant to reveal what the next token actually is must not under any circumstances fail that badly. > All call sites in the sources would have to be checked and quite few > would have to be rewritten if they were to use isstringfunc(). All call sites have to be checked anyway. |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-06-29 18:37:26
|
On Wednesday 29 June 2005 05:10 am, Hans-Bernhard Br=F6ker wrote:
> Juergen Wieferink wrote:
>=20
> > Such a function must not be called if the next token can be a key word=
=2E=20
> > An invalid expression would lead to an int_error().=20
>=20
> This, however, seems deeply wrong. A simple parsing helper function has=
=20
> no business bailing out to the command line.
This is a false concern. int_error() will not happen, because it is=20
trivial to check whether the next token is a user-defined function or not.
The missing part is to how to check the return type of that udf.
Consider that the following is a legal function definition:
f(plot,x) =3D (plot =3D=3D 0) ? sin(x) : sprintf("datafile.%d",plot) =20
So `plot f(0,x), f(1,x)` should be equivalent to
plot sin(x), "datafile.1"
The only alternative I see to trial evaluation is to add an infrastructure
for type-checking and type-propagation to the temp_at() code, and use it=20
to reject any function definition that propagates both string and non-string
types to the top of the evaluation tree.=20
I hasten to point out that so far as I know, the only place this is a real
issue is for the arguments to the `plot`, `splot`, and `fit` commands.
In all other cases it is safe to call try_to_get_string(), and then test
whether a string was actually returned or not. At worst you end up
evaluating a non-string expression twice, once to find out it's not a=20
string and a second time to store the numerical result instead. If this
is seen as a serious inefficiency, then at critical call sites the
code in try_to_get_string could be replicated in-line, keeping the
returned value for immediate use in either the string or non-string case.
=2D-=20
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
|
From:
<br...@ph...> - 2005-06-29 23:46:24
|
> Consider that the following is a legal function definition:
>
> f(plot,x) = (plot == 0) ? sin(x) : sprintf("datafile.%d",plot)
I think it shouldn't be. It's an invitation for utter confusion to
reign in users' heads. If it's any help: even C, in all its
carelessness for types, forbids the two expressions surrounding the : of
a ternay expression being of incompatible type.
We really have to take a decision here: either we have a typing system,
or we go the Perl way, which would imply a need for type-punning
functions or hacks like ''.<expressio> to work around unexpectedly wrong
types.
> The only alternative I see to trial evaluation is to add an
> infrastructure for type-checking and type-propagation to the
> temp_at() code, and use it to reject any function definition that
> propagates both string and non-string types to the top of the
> evaluation tree.
Exactly my point.
> At worst you end up evaluating a non-string expression twice, once to
> find out it's not a string and a second time to store the numerical
> result instead.
And if that expression has side-effects (like the recently proposed
system(<string>) or rand()), this is "at worst" can indeed be quite
bad.
> If this is seen as a serious inefficiency, then at
> critical call sites the code in try_to_get_string could be replicated
> in-line, keeping the returned value for immediate use in either the
> string or non-string case.
In-line expansion wouldn't be needed. A simple ptr argument where
try_to_get_string() can store the result of its attempted evaluation
would be quite enough --- it may have to be renamed then, though, to
evaluate_expression_of_as_yet_unknown_type() or something like that :-)
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2005-06-30 04:51:36
|
On Wednesday 29 June 2005 04:49 pm, Hans-Bernhard Br=F6ker wrote: > In-line expansion wouldn't be needed. A simple ptr argument where > try_to_get_string() can store the result of its attempted evaluation > would be quite enough --- it may have to be renamed then, though, to > evaluate_expression_of_as_yet_unknown_type() or something like that :-) We have such a function now. Its name is const_express(). try_to_get_string() is a just wrapper that allows it to work even if you configure without support for string variables. Using const_express() directly and checking the returned value is exactly what I meant by "in-line expansion". So I think we are both on=20 the same page. [and yes, I've always wondered why it was called const_express(), rather than evaluate_expression or the like]=20 =2D-=20 Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Juergen W. <wie...@fr...> - 2005-06-30 10:49:44
|
Hans-Bernhard Br=F6ker wrote:
> > Consider that the following is a legal function definition:
> >
> > f(plot,x) =3D (plot =3D=3D 0) ? sin(x) : sprintf("datafile.%d",plot)
>
> I think it shouldn't be. It's an invitation for utter confusion to
> reign in users' heads. If it's any help: even C, in all its
> carelessness for types, forbids the two expressions surrounding the : of
> a ternay expression being of incompatible type.
>
> We really have to take a decision here: either we have a typing system,
> or we go the Perl way, which would imply a need for type-punning
> functions or hacks like ''.<expressio> to work around unexpectedly wrong
> types.
>
> > The only alternative I see to trial evaluation is to add an
> > infrastructure for type-checking and type-propagation to the
> > temp_at() code, and use it to reject any function definition that
> > propagates both string and non-string types to the top of the
> > evaluation tree.
This is especially the case for "f(x)=3Dx?a:b" or even "f(x)=3Dx" and
"f(x)=3Da". As long as variables don't need to be declared, we are
stuck to the "perl way", I fear.
It may be possible to mimic execute_at() to obtain the resulting
type without actually executing the action table. This is quite a
lot of work and not very elegant.
> Exactly my point.
>
> > At worst you end up evaluating a non-string expression twice, once to
> > find out it's not a string and a second time to store the numerical
> > result instead.
>
> And if that expression has side-effects (like the recently proposed
> system(<string>) or rand()), this is "at worst" can indeed be quite
> bad.
>
> > If this is seen as a serious inefficiency, then at
> >
> > critical call sites the code in try_to_get_string could be replicated
> > in-line, keeping the returned value for immediate use in either the
> > string or non-string case.
>
> In-line expansion wouldn't be needed. A simple ptr argument where
> try_to_get_string() can store the result of its attempted evaluation
> would be quite enough --- it may have to be renamed then, though, to
> evaluate_expression_of_as_yet_unknown_type() or something like that :-)
Am I right on this:
If the next token on the command line is either a key word [or any
other token with a special meaning like '('], or it is an
expression. In the latter case, numerical and string values are
often treated in a different way. But either way, the expression
has to be evaluated. I am aware of the three exceptions "plot",
"splot" and "fit". Well, and possibly a function definition. :-)
And the cases where STRING_RESULT_ONLY is used, but in these cases,
a numerical value at that point is illegal.=20
I'd say, the conditional should generally be done after
const_express(). The expression is needed anyhow. Only the three
dummyexpression/filename cases (s?plot|fit) need to be treated
slightly different.
This is possible without evaluating anything twice. The major
drawback is that this doesn't work well with GP_STRING_VARS being
optional. [Could STRINGs be allowed without GP_STRING_VARS for this
special case?]
Juergen
|
|
From: Ethan M. <merritt@u.washington.edu> - 2005-06-30 20:09:31
|
On Thursday 30 June 2005 03:49 am, Juergen Wieferink wrote: > This is possible without evaluating anything twice. The major > drawback is that this doesn't work well with GP_STRING_VARS being > optional. [Could STRINGs be allowed without GP_STRING_VARS for this > special case?] Yes, but that isn't sufficient. The expression evaluation code would have to be modified so that const_express() will do something reasonable if the next token on the command line is a string literal. By the time you do that, I don't see that you've saved much over just enabling string variables. There's just not that much code involved in handling string variables per se. Any increase in overall size comes from the addition of built-in string functions like sprintf(). I don't see much down-side to permanently enabling string variables. There have been no reports of string variables breaking existing scripts or usage. There are some desireable un-implemented features, like the current discussion about using string-valued functions as arguments "plot/splot/fit". But other than that the feedback has been to point out places where the older test isstring() should be replaced by the new, more general, code. So far this has usually simplified the call site, rather than complicating it. It's just kind of tedious inspecting and revising the remaining 50+ instances of isstring() one by one. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Juergen W. <wie...@fr...> - 2005-07-01 11:51:32
|
Ethan Merritt wrote: > On Thursday 30 June 2005 03:49 am, Juergen Wieferink wrote: > > This is possible without evaluating anything twice. The major > > drawback is that this doesn't work well with GP_STRING_VARS being > > optional. [Could STRINGs be allowed without GP_STRING_VARS for this > > special case?] > > Yes, but that isn't sufficient. The expression evaluation > code would have to be modified so that const_express() will > do something reasonable if the next token on the command line > is a string literal. Of course. But this is quite trivial. Should probably be done in a wrapper, though. > By the time you do that, I don't see that you've saved much > over just enabling string variables. There's just not that much > code involved in handling string variables per se. Any increase in > overall size comes from the addition of built-in string functions > like sprintf(). Enabling strings in this special case would be to define "STRING" and to extend the union within "struct value" by "string_val". This itself should not lead to additional code in the executable. "value.v.string_val" would be used only within the wrapper and at the calling sites. > I don't see much down-side to permanently enabling string variables. Fine. I'll prepare a small patch this or next weekend to show more in detail what I mean. The main work will have to wait for a few weeks. Juergen |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-07-04 08:36:44
|
Juergen Wieferink wrote: > Ethan Merritt wrote: >>By the time you do that, I don't see that you've saved much >>over just enabling string variables. There's just not that much >>code involved in handling string variables per se. Any increase in >>overall size comes from the addition of built-in string functions >>like sprintf(). > Enabling strings in this special case would be to define "STRING" > and to extend the union within "struct value" by "string_val". This > itself should not lead to additional code in the executable. That would only be true if we were certain that all usages of the union are already fully decoded, i.e. the switch(value.type) all have cases for each of the allowed values, and there are no if(value.type == INTGR) or similar. That's not quite true right now, even though we're surprisingly close to that goal. |
|
From: Juergen W. <wie...@fr...> - 2005-07-04 09:23:53
|
Hans-Bernhard Broeker wrote: > Juergen Wieferink wrote: > > Enabling strings in this special case would be to define "STRING" > > and to extend the union within "struct value" by "string_val". This > > itself should not lead to additional code in the executable. > > That would only be true if we were certain that all usages of the union > are already fully decoded, i.e. the switch(value.type) all have cases > for each of the allowed values, and there are no if(value.type == INTGR) > or similar. That's not quite true right now, even though we're > surprisingly close to that goal. I don't understand this, and I feel really should. Is there really a problem with "if (value.type == INTGR)", or would it be the "else" part that makes problems? But I have to admit that it is quite inelegant to do what I proposed. The function I gave the not completely suitable name "is_dummy_func()" should also return a "char*", which is NULL if the expression is to be interpreted as a function. Juergen |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-07-04 09:36:43
|
Juergen Wieferink wrote: > I don't understand this, and I feel really should. Is there really > a problem with "if (value.type == INTGR)", or would it be the "else" > part that makes problems? If there's an else part, that'll almost certainly create problems. An "if (value.type != INTGR)" quite likely will. As will any "switch()" that doesn't have a case(STRING) or a default case that does a sensible thing. All such cases are likely to break if we enable the STRING entry in DATA_TYPES, but don't also turn on the rest of the string-variables stuff. |
|
From: Juergen W. <wie...@fr...> - 2005-07-04 17:36:55
|
Hans-Bernhard Broeker wrote: > Juergen Wieferink wrote: > > I don't understand this, and I feel really should. Is there really > > a problem with "if (value.type == INTGR)", or would it be the "else" > > part that makes problems? > > If there's an else part, that'll almost certainly create problems. An > "if (value.type != INTGR)" quite likely will. As will any "switch()" > that doesn't have a case(STRING) or a default case that does a sensible > thing. > > All such cases are likely to break if we enable the STRING entry in > DATA_TYPES, but don't also turn on the rest of the string-variables stuff. But the problem only occurs where the val.type is actually set to STRING. This wouldn't be allowed anywhere but within this special context of eval_plot() & Co. And uninitialized "struct value"s mustn't be used anyway because of the current string variable implementation. But I agree that my proposal is a Bad Thing. Juergen |
|
From: Ethan A M. <merritt@u.washington.edu> - 2005-07-04 18:49:09
|
On Monday 04 July 2005 02:23 am, Juergen Wieferink wrote: > Hans-Bernhard Broeker wrote: > > Juergen Wieferink wrote: > > > Enabling strings in this special case would be to define "STRING" > > > and to extend the union within "struct value" by "string_val". This > > > itself should not lead to additional code in the executable. > > > > That would only be true if we were certain that all usages of the > > union are already fully decoded, i.e. the switch(value.type) all have > > cases for each of the allowed values, and there are no if(value.type > > == INTGR) or similar. That's not quite true right now, even though > > we're surprisingly close to that goal. > > I don't understand this, and I feel really should. Is there really > a problem with "if (value.type == INTGR)", or would it be the "else" > part that makes problems? The internal evaluation code uses switch(value.type) statements everywhere. At the very least, if you add a new type without adding new case statements you will cause compiler warnings. Easy enough to do, but my feeling is that if you want to go to this trouble then we might just as well remove the conditional compilation flags around the string variable code and leave it at that. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: <wie...@we...> - 2005-07-04 21:14:13
Attachments:
call_leak-2005-07-04.patch
|
Ethan A Merritt wrote: > The internal evaluation code uses switch(value.type) statements everywhere. > At the very least, if you add a new type without adding new case > statements you will cause compiler warnings. Easy enough to do, but my > feeling is that if you want to go to this trouble then we might just as > well remove the conditional compilation flags around the string variable > code and leave it at that. I think I got the point. Thanks for your patience. I've already said that I regret ever having suggested this. :-) Removing GP_STRING_VARS would be nice, but isn't really neccessary. Tomorrow I'll upload a clean up for the last patch. BTW: During my tests, I've stumbled over a small memory leak, which took me quite long to locate. Eventually, it has been in there before my changes. The function f_call() pops a "struct value" from the stack. If this contains a string, it ought to be freed. Patch attached. Juergen |
