#1522 hang if {command block} has no closing bracket

[Anonymous]

On windows(5.0-rc3 mingw32, also official 4.6.6 build, couldn´t test on linux now), gnuplot hangs if a command block in curly braces is not closed within a script file loaded from the gp prompt.

== test.gp ==
print "test"
if (1) {
print "test2"
#}
=============

gp> load 'test.gp'

The code around src/command.c:377 is supposed to catch that, as far as i understood, but somehow doesn´t. Triggering a replot, e.g. with hitting "u" in the wxt terminal window, releases gp from the hang, displaying a garbled replot command after a "more>" prompt. Calling the same script from the command prompt

C:\test> gnuplot test.gp
test
"test.gp", line 3: Syntax error: missing block terminator }

gives the expected error.

[Bastian Märkisch]

The problem is on line 378 which reads

if (interactive || noinputfiles) {

The above tests succeeds when noinputfiles==true even if the mode is interactive==false as is the case for load. Changing that to

if (interactive || (interactive && noinputfiles)) {

solves that issue. Ethan, am I missing a use case?

[Ethan Merritt]

I don't know.
But that change is formally equivalent to not testing (noinputfiles) at all.

if (A || (A && B)) is the same as if (A)

[Bastian Märkisch]

Indeed. So the question is why is testing for interactive not sufficient?

[Ethan Merritt]

The long comment in command.c immediately following that test explains
why, doesn't it? If the input to gnuplot is coming via a pipe from
another program, it isn't an error to be in a state where a closing
'}' is still expected but hasn't arrived yet.

Come to think of it, that is exactly the case here also.
I don't think this is a bug at all.
Contrary to the bug report, gnuplot does not "hang". It's still
accepting input, which is expected to contain the closing '}'. If you
type this to the command line, or load another input script that
closes the bracketed clause, everything is fine.

So I think this should be considered "not a bug".
Or at any rate "not an error". Possibly it could be considered a bug
that no prompt is printed back to the terminal to remind you that more
input is expected. I'm not sure how to do that, however.

On Tue, Dec 16, 2014 at 11:20 PM, "Bastian Märkisch"
markisch@users.sf.net wrote:

Indeed. So the question is why is testing for interactive not sufficient?

---

[bugs:#1522] hang if {command block} has no closing bracket

Status: pending
Group: 5.0
Created: Sun Dec 07, 2014 09:38 PM UTC by Anonymous
Last Updated: Tue Dec 16, 2014 07:32 PM UTC
Owner: nobody

On windows(5.0-rc3 mingw32, also official 4.6.6 build, couldn´t test on linux now), gnuplot hangs if a command block in curly braces is not closed within a script file loaded from the gp prompt.

== test.gp ==
print "test"
if (1) {
print "test2"
#}
=============

gp> load 'test.gp'

The code around src/command.c:377 is supposed to catch that, as far as i understood, but somehow doesn´t. Triggering a replot, e.g. with hitting "u" in the wxt terminal window, releases gp from the hang, displaying a garbled replot command after a "more>" prompt. Calling the same script from the command prompt

C:\test> gnuplot test.gp
test
"test.gp", line 3: Syntax error: missing block terminator }

gives the expected error.

---

Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/gnuplot/bugs/1522/

To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

[Ethan Merritt]

Here is another case showing that it would be wrong to consider an unclosed bracket on exit from "load" to be an error.

file A:
do for [i=1:N] {
load "B"
load "B"
}

file B:
if (1) { print "something in brackets" }

Both A and B have properly paired brackets, but after returning from the first "load B" there is still an open bracket because of the do loop. This is not an error.

[Hans-Bernhard Broeker]

The correct condition would rather be that the count of open braces should be the same at the end of a loaded script as it was at its beginning. I.e. every loaded file has to have internally balanced braces. If it doesn't, that's at least grounds for a warning. If a loaded script closes a brace that was opened outside, that should be at least a warning, too.

[Ethan Merritt]

HBB: Yes, you are correct and the code does indeed seem to get that right. I should have constructed a test case for that example before offering it for consideration.