Project

General

Profile

Bug #6640

parsing bug for initial ",0000" for decimal variables or fields

Added by Constantin Asofiei almost 4 years ago. Updated over 1 year ago.

Status:
New
Priority:
Normal
Assignee:
Greg Shah
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 almost 4 years ago

  • Subject changed from parsing bug for initial ",0000" for decimal values or fields to parsing bug for initial ",0000" for decimal variables or fields

There is a problem with parsing an initial value of ",0000" for decimal variables or fields.

For example:

def var d as dec initial ",0000".
message d.

and:
ADD FIELD "cost" OF "Book" AS decimal 
  FORMAT "->>,>>9.99" 
  INITIAL ",00000"

This needs to be fixed both at schema and program parser.

I assume the leading comma is for the group separator, but some tests need to be done to ensure this. Also, we need to check if this must be configured in p2j.cfg.xml or not (i.e. if it must consider -numsep at the 4GL client startup parameter or some other configuration).

#4 Updated by Greg Shah almost 4 years ago

  • Assignee set to Greg Shah

#5 Updated by Greg Shah almost 4 years ago

Also, we need to check if this must be configured in p2j.cfg.xml or not (i.e. if it must consider -numsep at the 4GL client startup parameter or some other configuration).

At parsing time the number separator is not configurable. At least, in all my previous testing that has been true. And we have never seen customer code that shows otherwise.

On the other hand, this particular case requires that the initializer be a string literal. This form is something we do support but it is a kind of data type converson which we implement at parsing time. Since it is a literal, there is no reason to defer it to runtime, but there is a conversion involved. I will note this seems to be the same conversion used at runtime:

def var d as decimal init ",001".

/*
output:
1 1
*/
message d decimal(",001").

I'm looking deeper now.

#6 Updated by Vladimir Tsichevski over 1 year ago

Seems, the decimal separators are ignored completely when parsing a string to a number.
In OE this works as if the input strings have no commas at all:

def var d as dec initial "0,000012".
message d.
def var i as int initial "0,000012".
message i.
message integer("0,,,,,,000013.,,5").
message decimal("0,,,,,,000013.,,5").
message integer("0,,0000").

#7 Updated by Greg Shah over 1 year ago

What happens in OE when you set the decimal separator or group separator to different values?

You can set this on the command line with -E or at runtime using SESSION:SET-NUMERIC-FORMAT(). Most importantly, this should be tested with this set at the time the 4GL code compiles and when it runs.

Also available in: Atom PDF