Unexpected behaviour with IIF-statement and USUAL variables

[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

[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

[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

[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

[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

[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

[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