Re: user-defined function & string file name

[Juergen W. <wie...@fr...>]

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