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