Project

General

Profile

Bug #9967

unix separator in strings gets resolved as unicode separator

Added by Constantin Asofiei about 1 year ago. Updated about 1 year ago.

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

0%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:
reviewer:
production:
No
env_name:
topics:

History

#2 Updated by Constantin Asofiei about 1 year ago

This test when ran on Windows and Linux OpenEdge has different outputs:

def var ch as char.
ch = "Item\UnitPrice1".
message ch.
display "Item\UnitPrice3" with frame f1.

In linux, it outputs Item; on Windows, it outputs Item\UnitPrice

In FWD, we have <parameter name="unix-escapes" value="false" /> which is set in p2j.cfg.xml, depending on which OS is used to compile to r-code the 4GL code. By default, this gets set to !isWin (see p2j.cfg.Configuration.computeDerivedValues()). Throughout the FWD TRPL rules, a value of true is used as default (although this may just be not used as computeDerivedValues will set it to the proper value?). There is also ExpressionConversionWorker.progressToJavaString, which defaults to true.

When unix-escapes=true, FWD will try to resolve the escaped chars as a Unicode char; but in 4GL Linux, it seems that it just ignores (everything?) after the malformed escape sequence.

This task should both check all usages of unix-escapes to use the same default value (!isWin), although this will be needed only if computeDerivedValues is not being properly honored; and also expand the test and fix the conversion issue when setting unix-escapes=true for conversion.

Also available in: Atom PDF