Project

General

Profile

Bug #3212

OS inconsistency related to SET ... VALIDATE construct

Added by Ovidiu Maxiniuc over 7 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Normal
Target version:
-
Start date:
Due date:
% Done:

100%

billable:
No
vendor_id:
GCD
case_num:
version:

History

#1 Updated by Ovidiu Maxiniuc over 7 years ago

At the moment when the validate was implemented/fixed, the only test machine for P4GL was a 9.X on Linux. Later on, when the implementation was finetuned, some differences were noticed when the testcases were executed. A code like:

def var x as int extent 5.
set x validate(x > 0, "aa")  with frame f1. 

(thanks Constantin for the simplified testcase) ceased to compile. At this moment on linux machines, this procedure fails to compile:
** An array was specified in an expression, on the right-hand side of an 
assignment, or as a parameter when no array is appropriate or expected. (361) 

Something has changed in newest version of ABL 10.X.

However, from my tests this week, the very same procedure compiles and is successfully executed on both ABL 9.X and 10.X on windev01. This is a Windows machine. So it seems that even with latest reference P4GL version there are some differences in Progress syntax.

According to standard politics of considering the static converted code as valid, I am going to drop the current constraints from rules/annotations/validation_post.rules and allow the above testcase to be converted without errors. This is in concordance with some application environments where the code is mostly executed on Windows OS.

#2 Updated by Greg Shah over 7 years ago

I'm OK with this. Since it works in most places and only fails at compile time on 9.x in Linux, I think your approach is safe.

If we had a runtime error for this on 9.x Linux, then we would have to generate the error as expected because future customer apps might rely upon this behavior. But since the issue is compile-only, it is safe to enable this fully. Please put appropriate comments into validation_post.rules to explain this idea (both the fact that the behavior is a compile failure on 9.x in Linux but works properly elsewhere AND the idea that it is safe to ignore this for the purposes of conversion since no customer app can be broken by that decision).

#3 Updated by Constantin Asofiei over 7 years ago

Greg Shah wrote:

I'm OK with this. Since it works in most places and only fails at compile time on 9.x in Linux/Windows, I think your approach is safe.

Compilation fails on 10.2B on Linux, otherwise 10.2B/9.x on windows and 9.x on Linux (we can assume this from the old testing when the rules were initially added) it works.

#4 Updated by Greg Shah over 7 years ago

OK, just make that clear.

#6 Updated by Ovidiu Maxiniuc over 7 years ago

  • Start date deleted (11/18/2016)
  • Assignee set to Ovidiu Maxiniuc
  • Status changed from New to WIP

The update for this issue is contained in branch 3201b. After it was committed, the branch has passed standard regression testing and all ETF testing.

#7 Updated by Greg Shah over 7 years ago

  • % Done changed from 0 to 100
  • Project changed from Liberty to User Interface
  • Status changed from WIP to Closed

3201b was merged to trunk as rev 11132.

Also available in: Atom PDF