[SCXML] Incorrect and invalid ecmascript condition in IR test 459

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[SCXML] Incorrect and invalid ecmascript condition in IR test 459

Ate Douma
Hi,

I've just noticed an error in Implementation Report test 459 (ecmascript).

This test contains the incorrect (and invalid!) ecmascript condition:

   "Var4==0 | Var3 != 2".

AFAICT this condition probably should be coded as:

   "Var1==0 || Var3 != 2".

And because this condition is used as a negative test (transitions to "fail")
this test always succeeds, regardless, which probably is not intended :)

Ate

Reply | Threaded
Open this post in threaded view
|

Re: [SCXML] Incorrect and invalid ecmascript condition in IR test 459

David Junger
Le 28 déc. 2015 à 17:18, Ate Douma <[hidden email]> a écrit :
>
> I've just noticed an error in Implementation Report test 459 (ecmascript).
>
> This test contains the incorrect (and invalid!) ecmascript condition:
>
>  "Var4==0 | Var3 != 2".

It’s not technically invalid, and it’s not functionally broken either, although probably by accident.

‘|’ is a bitwise OR, has lower priority than comparison operators, and, when its operands are booleans (which they are here), it coerces them to 0 or 1 and so the result is 0 or 1, which is coerced back to the expected boolean.

                        David
Reply | Threaded
Open this post in threaded view
|

Re: [SCXML] Incorrect and invalid ecmascript condition in IR test 459

Ate Douma
On 2015-12-28 21:06, David Junger wrote:

> Le 28 déc. 2015 à 17:18, Ate Douma <[hidden email]> a écrit :
>>
>> I've just noticed an error in Implementation Report test 459 (ecmascript).
>>
>> This test contains the incorrect (and invalid!) ecmascript condition:
>>
>> "Var4==0 | Var3 != 2".
>
> It’s not technically invalid, and it’s not functionally broken either,
> although probably by accident.
>
> ‘|’ is a bitwise OR, has lower priority than comparison operators, and, when
> its operands are booleans (which they are here), it coerces them to 0 or 1
> and so the result is 0 or 1, which is coerced back to the expected boolean.
>
> David
>
Agreed, I probably shouldn't have said "invalid" :).
And indeed its not that this test always will succeed, but at least it (always)
fails to validate that Var1 and/or Var5 shouldn't be 0 at the end.

What I wanted to say is that there are two different type of errors with the
current expression:

   "Var4==0" should be "Var5==0" (error)
and
   bitwise OR "|" should be logical OR "||" (invalid)

I suspect this test has been modified heavily in the past as the comments
(including the description) don't add up to the applied logic either,
referring to either Var4 or var1 to be tested while I now think it is Var5 which
is intended to be tested (being not 0).

Anyhow, I think the current expression really is incorrect and also more
confusing as a negative test.
It would be much easier and strict when defined like:

   <transition cond="Var5 == 1 &amp;&amp; Var3 == 2" target="pass"/>
   <transition target="fail"/>

Ate