Re: SWITCH question
- Posted by jimcbrown (admin) Jan 07, 2018
- 1906 views
Unfortunately, that only fixes one problem, and there are at least 2 - probably 3 or more - with switch.
When using a built-in or library routine (for example: cos() or map:new(), etc) the stack is getting corrupted, or the object is being destroyed too soon.
Going to be hard to find, I fear.
Agreed.
I'm not sure what's going on with cos(0), but with map:new() and stack:new() we're calling delete_routine() before returning the integer.
So, for complex reasons we're storing this integer value internally as an atom (with the full eu atom struct, etc) just so we can attach the delete_routine routine_id to it. We call this autopromotion.
http://openeuphoria.org/forum/m/121848.wc
The fact that it's an atom on the inside, even though it looks like an integer when you print it out or test it with integer(), is probably what's making it break here.
There's a ticket for this. http://openeuphoria.org/ticket/963.wc
As for cos(), I'm not entirely sure what's going on here, but I do see this in be_runtime.c
object e_cos(object a) /* cos of an angle a (radians) */ { return (object)NewDouble( cos((double)a) ); } object De_cos(d_ptr a) /* double cos of a */ { return (object)NewDouble( cos(a->dbl) ); }
I wonder if it should be calling make_atom() instead of NewDouble? I'm just guessing here but it seems like it might be returning an atom internally always, even if the value can be stored as an integer.
cos() is doomed to fail as it will yield a non-integer result lots more often than INTs and the returned value has to be either TRUE or FALSE.
No, it doesn't. Literal strings are ok, as a counter-example.
What your 2nd example results in, I don't know, but if it isn't either 0 or 1, it will fail also.
Actually, they all are 1.
