gnuplot-beta

Code questions (strings and other things)

[Ethan M. <merritt@u.washington.edu>]

Any insight on the following questions?

util.c:
======
The routines os_error() and int_error() are identical
except for some VMS-specific conditional code in os_error() 
and a call to PRINT_SPACES_UNDER_PROMPT in os_error() 
instead of a newline in int_error().

Do we really need both routines?  What is the intended
use of os_error() as opposed to int_error()?

gp_alloc()
==========
I assume the intent is to use this function everywhere
rather than to use malloc() directly.  Without this
restriction, gnuplot's memory use code in alloc.c dies
dramatically if you use the free() macro.
So is it correct that all uses of malloc() are bugs?
getcolor.c in particular is an offender in this regard.
Should the guidelines in CodeStyle mention this restriction?


How to re-work isstring()?
========================
This question arises in connection with adding support
for string variables, and in particular for string-valued
functions.

Right now, the routine isstring() checks for the next
character of the input line being either a single quote
or a double quote.

Several people have suggested extending this to test
for a string constant (current code already does this),
a user-defined variable containing a string (this is easy)
or an expression returning a string.

This last case is driving me nuts.  I cannot figure out how
to determine the return type of an expression without
evaluating it. But in too many cases, trying to evaluate
the next token on the input line using const_express()
triggers int_error() rather than returning.  Any ideas?

SIde Note:   I did not add any special code to generate
string-valued user-defined functions.   As soon as even
one type of expression evaluates to a string, the existing
code generates them automatically in response to a
command like:
    myfunc(x) = <expression returning string>
e.g.
    f1(x) = "constant"
    f2(x) = sprintf("fmt",var)
    f3(x) = f1(x)+f2(x)

So, if we decide *not* to allow user-defined 
string functions, we still need a way to detect that
a function returns a string if only so we can forbid
someone to use it in a function definition.
In other words, this doesn't necessarily make the
problem of detection go away.



-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Code questions (strings and other things)

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:

>gp_alloc()
>==========
>I assume the intent is to use this function everywhere
>rather than to use malloc() directly.  Without this
>restriction, gnuplot's memory use code in alloc.c dies
>dramatically if you use the free() macro.
>So is it correct that all uses of malloc() are bugs?
>getcolor.c in particular is an offender in this regard.
>Should the guidelines in CodeStyle mention this restriction?
>

In what sense do you mean the memory use code dies dramatically?  The 
gp_alloc() routine could be made a definition or a function, e.g., in 
alloc.h define

#if USE_MEMORY_CHECK
    generic *gp_alloc __PROTO((size_t size, const char *message));
    generic *gp_realloc __PROTO((generic *p, size_t size, const char 
*message));
    void gpfree __PROTO((generic *p));
    #define alloc <some kind of error macro saying "use gp_alloc">
    #define realloc <some kind of error macro saying "use gp_realloc">
    #define free <some kind of error macro saying "use gpfree">
#else
    #define gp_alloc alloc
    #define gp_realloc realloc
    #define gpfree free
#endif

That will force developers to use gp_alloc consistently, but users--who 
likely won't know how to use gp_alloc--can leave that code out.

Dan

PS:  Why isn't gpfree, gp_free; consistent with gp_alloc, etc.?

Re: Code questions (strings and other things)

[Ethan M. <merritt@u.washington.edu>]

> 
> In what sense do you mean the memory use code dies dramatically?

If you enable CHECK_HEAP_USE, then gnuplot redefines  free()
to be an internal function 
	# define free(x) checked_free(x)

gp_alloc() allocates extra space and puts a checksum in the allocated
chunk of memory, which is checked when it is freed.
If the chuck was allocated directly with malloc() rather than gp_alloc()
then it doesn't contain this padding, and the attempt to validate this
"extra" space in the allocated chunk produces a segfault.

> PS:  Why isn't gpfree, gp_free; consistent with gp_alloc, etc.?

I wondered that as well.


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Code questions (strings and other things)

[Dave D. <dde...@es...>]

Ethan Merritt <merritt@u.washington.edu> writes:

>> 
>> In what sense do you mean the memory use code dies dramatically?
>
> If you enable CHECK_HEAP_USE, then gnuplot redefines  free()
> to be an internal function 
> 	# define free(x) checked_free(x)
>
> gp_alloc() allocates extra space and puts a checksum in the allocated
> chunk of memory, which is checked when it is freed.
> If the chuck was allocated directly with malloc() rather than gp_alloc()
> then it doesn't contain this padding, and the attempt to validate this
> "extra" space in the allocated chunk produces a segfault.
>
>> PS:  Why isn't gpfree, gp_free; consistent with gp_alloc, etc.?
>
> I wondered that as well.
>

It was a long time ago, but my guess is I was looking for some
particular leak or scribble, and the code was already using a
gp_alloc() wrapper, but was using free() directly. As a quick hack,
redefining free() was enough for what I was trying to do.


dd
-- 
Dave Denholm              <dde...@es...>       http://www.esmertec.com