Re: set terminal postscript lw 1.5; set output 'ps_symbols.ps' causes an error (was Re: "ps_symbols.gpi", line 2: unrecognized option during make ps_symbols.ps)

[Ethan A M. <sf...@us...>]

On Monday, 30 March, 2015 21:21:04 pl...@pi... wrote:
> On 03/30/15 17:38, sfeam wrote:
> > On Monday, 30 March 2015 03:48:41 PM Tatsuro MATSUOKA wrote:
> >
> >> The same phenomenon occurs on gnuplot on Ubuntu 14.04 LTS.
> >> gnuplot> set terminal postscript lw 1.5; set output 'ps_symbols.ps'
> >> Terminal type set to 'postscript'
> >> Options are 'landscape enhanced defaultplex \
> >>     leveldefault monochrome colortext \
> >>     dashlength 1.0 linewidth 1.5 butt noclip \
> >>     nobackground \
> >>     palfuncparam 2000,0.003 \
> >>     "Helvetica" 14  fontscale 1.0 '
> >>                                           ^
> >>           unrecognized option
> >>
> >> gnuplot>
> >>
> >> The above seem to be platform independent.
> >>
> >> Tatsuro
> >
> > Sorry for the error. It is fixed now.
> >
> > This is an example of a tyoe of programming error (failure to
> > check for end of command line) that is not exercised or caught
> > by running "make check".   Does anyone have suggestions about
> > how to add more stringent tests for debugging program changes?
> >
> > 	Ethan
> >
> 
> 'unrecognized option' suggests it was still parsing when,indeedn, it 
> should have been. Where is the end of line that it failed to find?
> 
> I don't see  what you are hoping to catch, or what the root cause of 
> this bug was.

The error was that it incremented the current token index, c_token,
past the semicolor.  Parsing is obviously supposed to stop and restart
after the semicolor, but the check has to be made explicitly using 
 if (END_OF_COMMAND) ...
In this case I forget to add that check, so the parser tried to
interpret the subsequent "set output ..." as if it were part of the
previous command.

A while back I caught a dozen or so examples of this same
error by manually editing the demo collection to add
  "  ;  junk_command=0 "
at the end of every line of each demo.  That had the effect of 
testing whether the implementation of every command used by the demos
correctly checked for end of command and therefore did not over-run
the semicolon.     

I guess what I'd like is a more generalized "command fuzzer",
to test whether incorrect input is correctly caught and reported
rather than triggering a segfault or other unpleasant behaviour.

	Ethan