Euphoria Ticket #937: assigning to integer destroys the object prematurely

Assigning a value that has destructor to an integer type results in destructor being called immediately .

Instead the back end should exit with an error message, ex.err created and so fourth with a message like this one:

/opt/euphoria-4.1.0/tests/t_c_integer_destroys.e:24  
<SOMENUMBER>: Cannot assign value with a destructor to an integer 
 
 
Public & Export & Global & Local Variables 

Example code :

include std/io.e 
include std/error.e 
include std/unittest.e 
 
type enum boolean T,F=0 end type 
 
boolean enable_my_close = F 
 
procedure my_close(integer fh) 
    if fh > io:STDERR then 
    	printf(io:STDERR, "Closing file %d\n", {fh}) 
    	if not enable_my_close then 
    		crash("premature file closing") 
    	end if 
        close(fh) 
    end if 
end procedure 
 
integer f_debug = open("example.log", "w") 
if f_debug =-1 then 
	f_debug = open("/dev/null", "w") 
  	puts(io:STDERR, "Unable to create log file.") 
else 
    f_debug = delete_routine(f_debug, routine_id("my_close")) 
end if 
 
enable_my_close = T 
 
test_report() 

Details

Type: Bug Report Severity: Major Category: Other
Assigned To: SDPringle Status: Accepted Reported Release:
Fixed in SVN #: View VCS: none Milestone: 4.0.6

1. Comment by jimcbrown Oct 19, 2015

Could there be a connection between this bug and the one in http://openeuphoria.org/forum/m/128827.wc ? (Though in that case I'm not sure why the bug would only affect 64bit translated code...)

2. Comment by SDPringle Oct 19, 2015

Back on topic. I think this happens because the value is assigned to the Integer and so the interpreter sees that it is an integer and converts it causing the destructor to be called.

3. Comment by SDPringle Nov 12, 2015

See: hg:euphoria/rev/98d54591dec3

changeset: 6391:98d54591dec3 branch: 4.0 user: Shawn David Pringle B.Sc. <shawn.pringle@gmail.com> date: Thu Nov 12 09:34:32 2015 -0300 files: tests/t_c_integer_destroys.d/control.err tests/t_c_integer_destroys.e description:

  • adds a test for ticket 937

4. Comment by SDPringle Nov 12, 2015

See: hg:euphoria/rev/49642f9cc4c0

changeset: 6392:49642f9cc4c0 branch: 4.0 tag: tip user: Shawn David Pringle B.Sc. <shawn.pringle@gmail.com> date: Thu Nov 12 10:36:17 2015 -0300 files: source/be_execute.c description:

  • fixes ticket 937 : except the line number is wrong!

5. Comment by SDPringle Nov 12, 2015

Translator also needs to be adjusted.

6. Comment by SDPringle Nov 12, 2015

See: hg:euphoria/rev/0f033cf8bc3e

changeset: 6393:0f033cf8bc3e branch: 4.0 user: Shawn David Pringle B.Sc. <shawn.pringle@gmail.com> date: Fri Nov 13 00:25:43 2015 -0300 files: source/compile.e description:

  • Make translated code throw an error when sole copy of an object is assigned to an integer. Ticket 937

7. Comment by SDPringle Dec 14, 2015

An error is thrown in both interpreter and translator but the interpreter with the Euphoria written backend does not repeat this behavior. The object doesn't get destroyed prematurely in that case. I am setting this to 'Fixed, Please Confirm'. If nobody objects by Christmas I will set it to Fixed.

It seems to me that runtime checking instead of compile time checking is the best we can really do with the way Euphoria is but it could be a lot better.

8. Comment by jimcbrown Dec 14, 2015

I think we need to modify the eu backend to throw the same error under the same conditions. Not urgent, however.

9. Comment by SDPringle Jan 26, 2016

See: hg:euphoria/rev/b2a358e226fd

changeset: 6404:b2a358e226fd branch: 4.0 user: Shawn David Pringle B.Sc. <shawn.pringle@gmail.com> date: Tue Jan 26 16:08:00 2016 -0300 files: tests/t_c_integer_destroys.d/control.err tests/t_c_integer_destroys.e description:

  • greatly simplified t_c_integer_destroys.e test: ticket 937

10. Comment by SDPringle Jan 26, 2016

See: hg:euphoria/rev/9574aff37501

changeset: 6405:9574aff37501 branch: 4.0 tag: tip user: Shawn David Pringle B.Sc. <shawn.pringle@gmail.com> date: Tue Jan 26 16:08:15 2016 -0300 files: source/be_execute.c description:

  • fixes ticket 937

11. Comment by SDPringle Jan 26, 2016

See: hg:euphoria/rev/8daae62cd18b

changeset: 6406:8daae62cd18b branch: 4.0 tag: tip user: Shawn David Pringle B.Sc. <shawn.pringle@gmail.com> date: Tue Jan 26 16:57:40 2016 -0300 files: tests/t_delete.e description:

  • more tests for destructors ticket 937

12. Comment by SDPringle Jan 26, 2016

See: hg:euphoria/rev/a946f8564442

changeset: 6407:a946f8564442 branch: 4.0 tag: tip user: Shawn David Pringle B.Sc. <shawn.pringle@gmail.com> date: Tue Jan 26 16:59:14 2016 -0300 files: tests/t_delete.e description:

  • more tests for destructors ticket 937

13. Comment by SDPringle Feb 03, 2016

The Euphoria language coded backend has no concept of references or the difference between an INT_ATOM() or an ATOM() like the C coded backend does. Implementing this in the backend of Euphoria language coded backend would require a lot of changes to this backend.

14. Comment by jimcbrown Feb 04, 2016

The fact that the Eu backend is not type aware in the same way as the C backend is a bug. Alas, I agree that it'd be quite a bit of work to correct this...

Maybe this should be a new, low importance and low priority bug or task, one that's specific to just the Eu backend? While it should be fixed someday, it's not going to hold up the release.

15. Comment by SDPringle in May

After seeing consequences of this fix, I have come to see that this error message solution is not acceptable. If you pass an integer with a destructor to a function that accepts integer, this end in an error message.

Generally speaking in Euphoria a number is a number and whether an integer is represented one way or another it should behave the same way. The consequence is code shouldn't rely on integers being represented by C int values.

Basically the new idea for the fix is if an integer has a destructor do not convert it to a C style int and just make sure the code following handles possible encoded double pointer representations of the integers.

16. Comment by jimcbrown in May

If I understand you correctly, there will be a performance hit when we change the code so all intgeres are always stored as atoms internally.

I'm ok with this though, computers are only getting faster after all. Correctness is more important than speed.

Search



Quick Links

User menu

Not signed in.

Misc Menu