ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

%CHECKR bug

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • %CHECKR bug

    I think I have found a bug in the RPG compiler or runtime - if I take a %CHECKR statement, and subtract an integer number from it, and the result is negative, it throws MCH1210 receiver value too small even if it isn't.

    Test case:
    Code:
           dcl-s str     char(8);
           dcl-s val     int(10);
    
             str = 'FFF';
    
             val = %checkR(' ':str) - 2;   // 1
    
             val = %checkR(' ':str) - 3;   // 0
    
             val = %checkR(' ':str);       // = 3
             val = val - 4;                // = -1
    
             // Should = -1, instead MCH1210 receiver value too small
             val = %checkR(' ':str) - 4;
    
            *inlr = *on;
            return;
    I am on v7.2, I don't know what PTF level.

    Can anyone else confirm?

  • #2
    My guess is that its using an unsigned integer as an intermediate result field (since %CHECK probably returns an unsigned). If that's the case, this isn't a bug...

    I would suggest reading about the format of numeric intermediate results, here: https://www.ibm.com/support/knowledg...asd/binops.htm

    Comment


    • #3
      I see, so because %checkr returns unsigned, and because the literal 4 is interpreted as unsigned, the result is treated as unsigned and does not allow -1 even though the destination is signed and can hold -1.

      That explains why these 2 variants work:
      Code:
             dcl-s str     char(8);
             dcl-s val     int(10);
      
               str = 'FFF';  
               val = %int(%checkR(' ':str)) - 4;
               val = %checkR(' ':str) + (-4);
      That makes sense, though it is a bit counter-intuitive. I always thought intermediary results limitations only applied to when you had multiple calculations in one statement: e.g. "a = b + (c - d);", where an intermediary result for (c - d) would be computed first which would then be added to b

      Though the way that page is worded, I would expect "a = 4 - 3;" to fail because both operands are literals and therefore unsigned, but it doesn't.

      Comment

      Working...
      X