OpenEuphoria

Euphoria Ticket #829: goto leads to no init checking

• Reported by mattlewis Dec 20, 2012
• 7 comments

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 ) 

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

Details

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.)

7. Comment by SDPringle Dec 01, 2020

Fixed in Git change 4e288a7a93e9c04b94bbb67be68406c5ea8d1c8d

Include: