Quantcast

Patches to clean up string-handling corner cases

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Patches to clean up string-handling corner cases

Ethan Merritt
On Saturday 04 June 2005 10:06 am, Jürgen Wieferink wrote:
> Today I've searched the code for other occurances of
> 'free(...string_val)' and replaced them by 'gpfree_string'.

Great. I put that one in cvs.

> The third patch keeps track of backslashes within double quoted strings.

I had forgotten about this issue.  I've put your fix into cvs
because it is better than the current state of affairs.
But I don't think this is the end of the story.  I see it as
applying a bandaid to the deeper problem of extending the
distinction between single-quoted strings and double-quoted
string constants to string variables.

Currently the check for single- or double- quotes is made at
the time a string constant is parsed, as in:
  A = "1\n2"
  B = '1\n2'
  if (A ne B) print "Strings are not equal"

But if you assign a value to a string variable via some more
complex path, including your new system() function, then there
is no check for whether embedded special characters should be
given the single-quote treatment (store raw input) or the
double-quote treatment (add \ in front of certain characters).

I don't have a specific example of when this would cause a
problem, but it makes me uneasy.  I think it might be better to
remove the single/double quote processing from the parser, and
instead *always* store a string in its "raw" form, and add a
separate flag to indicate whether it is to be expanded or not
when printed.

>The second problem I found is revealed by:
>  set macros
>  foo = "print foo"
>  @foo
>  print "@foo"
>  print "\"@foo\""
>  print "\"@foo"; @foo

I haven't looked at this one yet, but there's another unresolved
issue as well, pointed out by Petr Mikulik a while back.
As you can see from the sequence below, it does not
work to define and invoke a macro on the same input line:

gnuplot> set macros
gnuplot> foo = "1"; print @foo;  foo = "2"; print @foo
         warning: foo is not a string variable
         warning: foo is not a string variable

gnuplot> foo = "1"; print ;  foo = "2"; print
                          ^
         constant expression required

gnuplot> show var

        Variables:
        pi = 3.14159265358979
        foo = 1

gnuplot> foo = "2"; print @foo;  foo = "3"; print @foo
1
1


--
Ethan A Merritt       [hidden email]
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r 
_______________________________________________
gnuplot-beta mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Patches to clean up string-handling corner cases

Juergen Wieferink
> Currently the check for single- or double- quotes is made at
> the time a string constant is parsed, as in:
>   A = "1\n2"
>   B = '1\n2'
>   if (A ne B) print "Strings are not equal"

In my opinion, it should be this way.  When I have to choose between
single and double quotes, I take the ones which are more
convenient in the current situation.  I do not want to take into
account what can happen to them later.

Quite a few programming language offer both single and double quotes
having different syntax (bash, perl, ...).  But I'm not aware of a
single one that keeps track wether a given string has been typed in
this or that way.

> But if you assign a value to a string variable via some more
> complex path, including your new system() function, then there
> is no check for whether embedded special characters should be
> given the single-quote treatment (store raw input) or the
> double-quote treatment (add \ in front of certain characters).

It works the way I would want it to have.  You can't input a newline
character directly on the command line, so there has to be a way to
get it into strings nevertheless.  There is no such problem within
pipes.  If I need a newline in the string returned by system(), I'll
use one.  I don't see any need for escape sequences in this case.


> As you can see from the sequence below, it does not
> work to define and invoke a macro on the same input line:
>
> gnuplot> set macros
> gnuplot> foo = "1"; print @foo;  foo = "2"; print @foo
>          warning: foo is not a string variable
>          warning: foo is not a string variable
>
> gnuplot> foo = "1"; print ;  foo = "2"; print
>                           ^
>          constant expression required

I wouldn't really expect this to work.


Juergen



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
gnuplot-beta mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Loading...