Page 1 of 1
Unexpected behaviour with IIF-statement and USUAL variables
Posted: Thu Oct 25, 2018 12:46 pm
by Thomas
Hi all,
i have a problem (bug?) with IIF-statement and boolean/usual values using
Vulcan dialect.
Could you please check this?
1.) If the then-part or else-part uses a variable that is declared as USUAL and the value is FALSE, the negation of that value will lead to a wrong result.
I have the following demo code:
Code: Select all
LOCAL lValue2 := FALSE AS LOGIC
LOCAL lValue3 := FALSE AS USUAL
LOCAL lResult := FALSE AS LOGIC
lResult := IIF(FALSE, !lValue2, !lValue3)
// The result is 'false', expected is 'true' (--> !lValue3)
There is no problem if the variable is declared as LOGIC or negating a usual-variable with value TRUE!
2.) If the result variable is also declared as USUAL, the result of the statement is undefined:
Code: Select all
LOCAL lValue1 := FALSE AS LOGIC
LOCAL lValue2 := FALSE AS LOGIC
LOCAL lValue3 := FALSE AS USUAL
LOCAL lResult := FALSE AS USUAL
lResult := IIF(lValue1, !lValue2, !lValue3)
// ??? The result is undefined, debugger shows "unable to read memory".
If the value to negate is TRUE, the result of the statement is null:
Code: Select all
lValue3 := TRUE
lResult := IIF(lValue1, !lValue2, !lValue3)
// The result is null (NIL)
Regards
Thomas
Unexpected behaviour with IIF-statement and USUAL variables
Posted: Thu Oct 25, 2018 2:23 pm
by FFF
Thomas,
you didn't provide which environment you use...
I had a go with X# Runtime in "Vo" Dialect in XIDE.
First result like yours,
second "NIL"
third "NIL"
Switching to X# App/VN, using the VN-Runtime
#1 FALSE, if i define lResult as Usual, it crashes
#2 "NIL"
#3 "NIL"
Karl
Unexpected behaviour with IIF-statement and USUAL variables
Posted: Thu Oct 25, 2018 2:57 pm
by Thomas
Hi Karl,
I use Visual Studio 2017, the X# compiler runs in Vulcan dialect.
For a small demo console application to reproduce the problem I've used the standard "language compatibility switches" for a X# project. In our productive system we use other language compatibility switches, but is the same problem.
Thomas
Unexpected behaviour with IIF-statement and USUAL variables
Posted: Thu Oct 25, 2018 9:51 pm
by Chris
Hi Thomas,
Thanks a lot for your report, I do see the problems, with a quick look I could not tell what's causing it exactly, but Robert or someone else will be able to figure this out.
Btw, yeah, since the X# runtime is almost ready now, as Karl says please mention in your reports if you use that one or the vulcan runtime (although in this case the problem appears to be a compiler one. so applies to both). Regarding which IDE you use, this should make no difference, as long as you are using the same compiler settings.
Chris
Unexpected behaviour with IIF-statement and USUAL variables
Posted: Mon Nov 05, 2018 3:44 pm
by Thomas
Hi Chris,
do you have any news regaring this problem? Could anybody figure out what causes the problem and can you perhaps already tell me when we can get a fix for it?
Btw, we use the Vulcan runtime...
Thanks
Thomas
Unexpected behaviour with IIF-statement and USUAL variables
Posted: Mon Nov 05, 2018 4:22 pm
by robert
Thomas,
I will try to fix this this week. It will then become part of beta 7.
There is no release date for Beta 7.
We provide FOX subscribers with interim updates for things like this.
But you're not a FOX subscriber, so it will most likely be included with the next public release. That will most likely be available end of November - early December.
Robert
Unexpected behaviour with IIF-statement and USUAL variables
Posted: Wed Nov 07, 2018 3:24 pm
by robert
Thomas,
I looked at this problem today and is caused by an error in our IIF handling code. We try to determine the types of the 2nd and 3rd expression to see if they are the same. When they are not then we add a cast to USUAL (in the VO dialect) and let it be resolved at runtime. We have to do this because the Roslyn compiler expects that both expressions return the same type.
The problem is that the compiler gets confused by the ! or .NOT. operator. When the expression after these operators is a USUAL then the compiler (incorrectly) assumes that the .NOT. from this expression is also USUAL. And that is not true: The Operator method on the USUAL type that is called for the NOT operation returns a LOGIC and not a USUAL.
As a result the code that gets generated is incorrect.
To avoid this problem, I suggest to avoid using the ! or .NOT. operator on USUAL expressions inside an IIF expression until the next build.
Robert