Re: Operand inversion in motov.c

Hmmm ... what to do here is a tough question to answer. I'd like to do  
some expression evaluation tests in other languages to see the order in  
which assignments get evaluated in them. A test like

int output (int i){ print i; return i;}
foo[output(27)] = output(30);

would tell us the order in which the left and right sides get evaluated  
... My overall feeling is that we should avoid having a non-standard  
equals operator. Even if that means we need to re-think our  
implementation of this feature.

-Dave

On Tuesday, May 6, 2003, at 10:05  AM, Stefano Corsi wrote:

> Hi Dave,
>
> I had to invert the order of evaluation in motov_assign, cause  
> otherwise I had
> no rval available to check operator existence in motov_array_rval.  
> Before it
> was:
>
>     /* Get the LValue from the left side */
>     motov(uc_operand(p, 0));
>     lval = opstack_pop(env);
>
>     /* Get the RValue from the right side */
>     motov(uc_operand(p, 2));
>     rval = opstack_pop(env);
>
> Now it's:
>
>     /* Get the RValue from the right side */
>     motov(uc_operand(p, 2));
>     rval = opstack_pop(env);
>
>     /* Save current rval value */
>     env->current_rval = rval;
>
>     /* Get the LValue from the left side */
>     motov(uc_operand(p, 0));
>     lval = opstack_pop(env);
>
>     /* Clear current rval value */
>     env->current_rval = NULL;
>
> Of course, the previous version was much better from a verifier point  
> of view,
> because you could first verify the left side of the assignment and  
> then the
> right. But the inversion is the only way to produce the rval before
> motoi_array_lval gets called.
>
> The bf_comments test fails now, but just because the print order of  
> the error
> messages is inverted.
>
> bf_comments.moto.................fail.....ok.......n/a......n/ 
> a......n/a
>
> What should we do? Change the test or find another way to evaluate  
> lval []
> overloaded operators?
>
> Stefano
>
>