Bug #3212
OS inconsistency related to SET ... VALIDATE construct
100%
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.