Hi John, Peter and Ken:

I know a ticket has been entered and Appeon is looking into it, but wanted to add some thoughts...

It doesn't surprise me too much that when doing a comparison via the IF statement that promotion does not occur, with CONSTANTS, because my understanding is that promotion does not occur (or should not based upon the Help) with Relational operators (=, <= etc.) versus Arithmetic operators (+, -, / etc.). And maybe it has nothing to do with promotion but maybe since it is being declared and assigned at compile time as a certain datatype then it occupies the maximum number of bits required for a longptr at that point and the fact that both have a value of 177 is immaterial, they just won't compare to be the same...again, this is when using an IF statement, see below for a different result using CHOOSE CASE.

It more surprises me that promotion DOES occur with the non-CONSTANT expressions, such as with the test of ll_longptr and li_int in an IF statement. Or, maybe promotion is not taking place and it is concluding they are equal for a different reason. Possibly because they are the same value, maybe due to being declared with literals, but not how many bits they require for storage. What changes things is if you assign ll_longptr to li_int during li_int's declaration the comparisons are not equal as li_int ends up being equal to 0, which does not happen if you assign another integer variable to li_int during its declaration. However, if you don't give li_int a value during its declaration and assign ll_longptr to li_int afterwards then it works as before (demotion??). If it works, but not because of using literals, and assuming the Help is correct re promotion not taking place when using Relational operators, feels like something is not quite right.

What's interesting with the CHOOSE CASE statement and a CONSTANT of one data type and a non-CONSTANT of a different data type is that it seems to depend upon whether the CONSTANT is the testexpression (it does occur) versus the CONSTANT being one of the expressionlist entries (it does not occur). So in your example John, if you switch these around in your second CHOOSE CASE test you will see the "Alert 2" message. Again, planned behavior or is something not quite right!? FYI...in your fourth IF statement you actually compared ll_longptr (instead of ll_longptr_constant) to li_int_constant, but even when changed the message result is still the same as far as what occurs which is they are not considered equal.

While the above may be interesting, it's still confusing re the result of all these comparisons and so hopefully the ticket will yield some clarity. Maybe all is well and there is a logical explanation or maybe there is a bug, or two, that needs to be sorted out.

Again, just my thoughts and thanks for reading.

Regards,

Mark

Thanks John, for your response.

It is a curious thing.

I had tested IF statements for the comparison I cared about, and it worked like I expected for an experiment, so I didn't mention, and was surprised you showed that comparison with a different result. 

So I looked at the longptr to constant integer comparison that contradicted my earlier thoughts, and find things get a little weirder.

I had to compare my test that gave a different result with your test, and trial and error the difference out, detailed below.

With:

// Demonstrate IF statement doing strange things with longptr and constant integer
longptr ll_longptr = 177
CONSTANT integer li_integer_constant = 177
String ls_msg = ""
ls_msg = ""  // Why does this line make the below false?

if (ll_longptr = li_integer_constant) then
   ls_msg += "ll_longptr = li_integer_constant"
else
   ls_msg += "ll_longptr <> li_integer_constant" // This occurs.
end if

MessageBox("If-Statement Results",ls_msg)

I get:

With commenting out the unrelated line ls_msg = "": 

// Demonstrate IF statement doing strange things with longptr and constant integer
longptr ll_longptr = 177
CONSTANT integer li_integer_constant = 177
String ls_msg = ""
// ls_msg = ""  // <--- Comment this line out and get an equal result!

if (ll_longptr = li_integer_constant) then
   ls_msg += "ll_longptr = li_integer_constant" // This occurs.
else
   ls_msg += "ll_longptr <> li_integer_constant" 
end if

MessageBox("If-Statement Results",ls_msg)

I get:

It took a while to reduce this down to a seemingly unrelated statement, and it is so odd, I wonder if typos or human error in my experiments is the cause.

How does the presence of a ls_msg = "" make any difference to the below comparison?

Without trusting the test harness, I'm not sure of the test itself.

Cheers, Peter.

An issue like this one never fails to intrigue me, Peter.

I was curious to see if these results were limited to Choose-Case statements or they occur in If-statements, so I extended your example script (thank you very much for including that, by the way) as follows:

// Demonstrate CASE statement does not work comparing LONGPTR to CONSTANT INT
longptr ll_longptr = 177
int li_int = 177
CONSTANT int li_int_constant = 177
CONSTANT longptr ll_longptr_constant = 177
String ls_msg

CHOOSE CASE ll_longptr
   CASE li_int
      MessageBox("Alert 1", 'll_longptr = li_int') // This does occur. NON-constant integer.
END CHOOSE

CHOOSE CASE ll_longptr
   CASE li_int_constant
      MessageBox("Alert 2", "case ll_longptr = li_int_constant") // This does not occur. CONSTANT integer
end choose

If ll_longptr = li_int Then
   ls_msg = "ll_longptr = li_int" // <- This occurs.
Else
   ls_msg = "ll_longptr <> li_int"
End If

ls_msg += "~r~n~r~n"
If ll_longptr = li_int_constant Then
   ls_msg += "ll_longptr = li_int_constant"
Else
   ls_msg += "ll_longptr <> li_int_constant" // This occurs.
End If

ls_msg += "~r~n~r~n"
If ll_longptr_constant = li_int Then
   ls_msg += "ll_longptr_constant = li_int"
Else
   ls_msg += "ll_longptr_constant <> li_int" // <- This occurs.
End If

ls_msg += "~r~n~r~n"
If ll_longptr = li_int_constant Then
   ls_msg += "ll_longptr_constant = li_int_constant"
Else
   ls_msg += "ll_longptr_constant <> li_int_constant" // <- This occurs.
End If

ls_msg += "~r~n~r~n"
If ll_longptr = 177 Then
   ls_msg += "ll_longptr = 177" // <- This occurs.
Else
   ls_msg += "ll_longptr <> 177"
End If

ls_msg += "~r~n~r~n"
If ll_longptr_constant = 177 Then
   ls_msg += "ll_longptr_constant = 177"
Else
   ls_msg += "ll_longptr_constant <> 177" // <- This occurs.
End If

MessageBox("If-Statement Results",ls_msg)

As indicated by the comments, here is the result when run from the 2019 R3 Build 2670 IDE:

It appears that the normal auto-promotion of integer-type data types you would expect to happen prior to the comparison does NOT occur when a constant is present on either side of the comparison operator.