Bug #6640
parsing bug for initial ",0000" for decimal variables or fields
0%
History
#2 Updated by Constantin Asofiei almost 2 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 2 years ago
- Assignee set to Greg Shah
#5 Updated by Greg Shah over 1 year 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.