Unexpected behaviour with IIF-statement and USUAL variables

More
3 weeks 14 hours ago #1 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:
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:
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:
lValue3 := TRUE
lResult := IIF(lValue1, !lValue2, !lValue3) 
// The result is null (NIL)

Regards
Thomas

Please Log in or Create an account to join the conversation.

More
3 weeks 12 hours ago #2 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

Please Log in or Create an account to join the conversation.

More
3 weeks 12 hours ago #3 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

Please Log in or Create an account to join the conversation.

More
3 weeks 5 hours ago #4 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

XSharp Development Team
chris(at)xsharp.eu

Please Log in or Create an account to join the conversation.

More
1 week 3 days ago #5 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

Please Log in or Create an account to join the conversation.

More
1 week 3 days ago #6 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

XSharp Development Team
The Netherlands
This email address is being protected from spambots. You need JavaScript enabled to view it.

Please Log in or Create an account to join the conversation.

More
1 week 1 day ago #7 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

XSharp Development Team
The Netherlands
This email address is being protected from spambots. You need JavaScript enabled to view it.

Please Log in or Create an account to join the conversation.