Project

General

Profile

Bug #2265

Extent initializer compiles fine on scalar variable definition

Added by Hynek Cihlar over 10 years ago. Updated over 10 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
03/26/2014
Due date:
% Done:

0%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:

History

#1 Updated by Hynek Cihlar over 10 years ago

The following code snippet compiles without errors producing invalid Java code.

def var i1 as int init [1, 2, 3].
def var i2 as int extent 0 init [1, 2, 3].

Both variable definitions are scalar definitions, the extent initializers must not be allowed here. The expected outcome is to get a meaningful error message from the compiler.

#2 Updated by Constantin Asofiei over 10 years ago

Hynek, P2J will always convert valid 4GL code, which can compile in Progress. We do not want and will not start hunting each and every compile error. So your problem is not a real problem, as the code is not valid 4GL code.

#3 Updated by Hynek Cihlar over 10 years ago

I probably wasn't descriptive enough. The code sample doesn't compile in Progress, it gives "Too many initial values for program variable i. (685)" error message. Yet it compiles during P2J conversion resulting in invalid Java code.

#4 Updated by Constantin Asofiei over 10 years ago

Hynek Cihlar wrote:

I probably wasn't descriptive enough. The code sample doesn't compile in Progress, it gives "Too many initial values for program variable i. (685)" error message.

Exactly. We don't want and we will not support this. All code passed to the conversion engine is assumed to be valid 4GL code, which compiles in 4GL. So your input is not expected to be received by the conversion engine: the solution in such cases is to fix the 4GL code, not the P2J conversion/runtime code.

#5 Updated by Hynek Cihlar over 10 years ago

I see now. Can you then close the issue?

#6 Updated by Greg Shah over 10 years ago

  • Status changed from New to Closed

Also available in: Atom PDF