Re: Code questions (strings and other things)

[Hans-Bernhard B. <br...@ph...>]

On Tue, 27 Jul 2004, Ethan Merritt wrote:

> 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() 

That conditional is not really VMS-specific. The real difference is
right in the #else branch of that: the perror() call. 

In a nutshell: os_error is used to report errors detected by the OS (i.e.
decode errno to a readable message and show it), int_error is for error
conditions internal to gnuplot.

> gp_alloc()
> ==========
> I assume the intent is to use this function everywhere
> rather than to use malloc() directly. 

Well, everywhere in the code that goes into gnuplot itself.  gplt_x11.c
and the other platform-specific drivers don't use it.

> So is it correct that all uses of malloc() are bugs?

Essentially yes.


> getcolor.c in particular is an offender in this regard.

Caution, there.  getcolor.c gets compiled into gnuplot_x1.c, too.

> Should the guidelines in CodeStyle mention this restriction?

Yes.

> 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. 

Evaluation shouldn't be necessary --- but parsing the expression will be.
That's why I at one point suggested the

	''+{rest of expression}

hack.  It starts off with a string literal, so isstring() will
recognize 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?

How about cloning const_express and having the copy return an error code
rather than bailing out by itself?

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.