1. Peter Thiem
  2. PowerBuilder
  3. Wednesday, 13 October 2021 02:50 AM UTC

Hi,

I am upgrading an application from Powerbuilder Classic 12.5 to Powerbuilder 2021 (build 1288).

For me, the case statement malfunctions and returns false, when a long pointer is the "testexpession" and a constant integer is the "expressionlist", when I was expecting it to return true. 

This pattern is used in this application in using the message.wordparm variable to decide how to handle message.

A minimal example is 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

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

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

I find it unexpected that a constant behaves differently from a non-constant in this example.

Is this an expected behaviour, a known defect, depends on the 32/64 bitness of the execution, or affects only me perhaps, or example is faulty?

In any case, I will just work around it for now.

Cheers, Peter

PS. In powerbuilder classic 12.5, message.wordparm appears to be Long, rather than Longptr, and the application was fine.

 

Accepted Answer
Ken Guo @Appeon Accepted Answer Pending Moderation
  1. Wednesday, 13 October 2021 06:18 AM UTC
  2. PowerBuilder
  3. # Permalink

Hi Peter,

Thank you for posting this issue, I ran your and John's sample code, as you said, PB Longptr type has this defect when using CONSTANT or comparing with other CONSTANT types.
Can you run the same code in PB 12.5? PB 12.5 should not recognize the longptr type. As far as I know, the longptr type is a new type added in SAP PB 12.6 and this defect also exists in SAP PB 12.6.


I suggest you open a ticket at https://www.appeon.com/standardsupport/newbug so our support team can adequately track, prioritize and handle the issue.

For now, I suggest that you work it around by not comparing variables of type Longptr to CONSTANT variables.

Regards,
Ken

Comment
  1. Peter Thiem
  2. Wednesday, 13 October 2021 21:55 PM UTC
Thanks Ken, I'll raise a bug, work around it, now that I know it (probably) is not just some silly thing I did!
  1. Helpful
There are no comments made yet.
Mark Goldsmith Accepted Answer Pending Moderation
  1. Thursday, 14 October 2021 13:22 PM UTC
  2. PowerBuilder
  3. # 1

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

Comment
  1. Mark Goldsmith
  2. Thursday, 14 October 2021 13:49 PM UTC
I just re-read Peter's OP...apologies on mentioning the CHOOSE CASE working when the testexpression and expressionlist are switched around as that wasn't new information. I did read that in Peter's OP but by the time I did some testing and got around to putting together a reply I completely forgot about it already being pointed out.



Regards,

Mark
  1. Helpful
  1. John Fauss
  2. Thursday, 14 October 2021 14:15 PM UTC
Very thoughtful and insightful analysis & comments, Mark - Thanks for contributing to the discussion!
  1. Helpful
  1. Mark Goldsmith
  2. Thursday, 14 October 2021 14:36 PM UTC
Thanks John.
  1. Helpful
There are no comments made yet.
Peter Thiem Accepted Answer Pending Moderation
  1. Wednesday, 13 October 2021 06:44 AM UTC
  2. PowerBuilder
  3. # 2

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.

 

 

Comment
  1. Ken Guo @Appeon
  2. Wednesday, 13 October 2021 08:21 AM UTC
Hi Peter,



This issue is really strange. For your case, the issue doesn’t happen if you use the following statement. It may be related to the accuracy of the data.

if ( int(ll_longptr) = li_integer_constant) then

or

if (ll_longptr = long(li_integer_constant)) then



But if it’s ll_longptr_constant, then this workaround does not apply.



Regards,

Ken
  1. Helpful
There are no comments made yet.
John Fauss Accepted Answer Pending Moderation
  1. Wednesday, 13 October 2021 04:50 AM UTC
  2. PowerBuilder
  3. # 3

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.

Comment
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.
We use cookies which are necessary for the proper functioning of our websites. We also use cookies to analyze our traffic, improve your experience and provide social media features. If you continue to use this site, you consent to our use of cookies.