Euphoria Ticket #829: goto leads to no init checking

The following causes a machine crash at if y then:

procedure foo( integer x ) 
	if x then 
		goto "x" 
	end if 
	integer y = 1 
	label "x" 
	if y then 
		? y 
	end if 
end procedure 
foo( 1 ) 

This only seems to happen if the variable is declared after the goto. The same code at top level has correct init checking.

I originally found this with the following code:

include std/net/url.e 
parse("file:///etc/hosts") 

Details

Type: Bug Report Severity: Blocking Category: Front End
Assigned To: unknown Status: New Reported Release: 4.0.5
Fixed in SVN #: View VCS: none Milestone:

1. Comment by useless_ Dec 20, 2012

HEY! ! Stop causing trouble for GOTO! !

This is a bug in user programming, not a bug in goto. You must declare before use. Personally, i don't like inline declaring anyhow, you risk multiple declarations of the same var.

useless

2. Comment by jimcbrown Dec 20, 2012

This is a valid bug - misuse of goto in this way should cause a crash with a human readable error message explaining what happened, not a machine-level exception.

3. Comment by useless_ Dec 20, 2012

I disagree, and you knew i would.

The error isn't in the use of goto. The error is not doing flow control adhereing to the basic premise of declaration before use. Put the declarations at the top of the routine, and all is well.

You can fix the symptom by scanning the routines twice before program execution (test everything for scope after a goto lable as the start of a new routine), but if this adds another second to startup, i vote against it.

useless

4. Comment by jimcbrown Dec 20, 2012

I feel that I am forced to agree with you: this bug is not a misuse of goto, strictly speaking. The bug that causes the symptom lies elsewhere.

However, I feel that we are forced to accept the fix or workaround for this, even if it means extra scanning that slows down the parser by many seconds...

5. Comment by DerekParnell Dec 21, 2012

The bug is that it causes a machine crash rather than generate a not assigned error message. The code above is effectively the same as ...

procedure foo( integer x )  
    integer y 
    if x then  
        goto "x"  
    end if  
    y = 1  
    label "x"  
    if y then  
        ? y  
    end if  
end procedure  
foo( 1 )  

6. Comment by jimcbrown Dec 21, 2012

Derek, I already said that back in comment #2.

You agree with the need to fix this, even if it causes a slowdown somewhere? (I'm not convinced that fixing this would necessarily require a slowdown, so this is just a hypothetical question.)

Search



Quick Links

User menu

Not signed in.

Misc Menu