== Why is this an issue?

Moving a large number into a small field will result in data truncation. Generally, numeric values are truncated from the left. However, in the case of floating point values, when the target field has too little precision to hold the value being moved to it, decimals will be truncated (not rounded!) from the right.


In any case, data loss is always the result when too-large values are moved to too-small fields.


=== Noncompliant code example

[source,cobol]
----
01 NUM-A   PIC 9(2)V9.
*> ...

    MOVE 88.89   TO NUM-A  *> Noncompliant. Becomes 88.8
    MOVE 178.7   TO NUM-A  *> Noncompliant. Becomes 78.7
    MOVE 999.99 TO NUM-A  *> Noncompliant. Truncated on both ends; becomes 99.9
----


=== Compliant solution

[source,cobol]
----
01 NUM-A   PIC 9(3)V99.
*> ...

    MOVE 88.89   TO NUM-A
    MOVE 178.7   TO NUM-A
    MOVE 999.99 TO NUM-A
----


== Resources

* https://cwe.mitre.org/data/definitions/704[MITRE, CWE-704] - Incorrect Type Conversion or Cast

=== Related rules

* S3921 - for truncation of string values


ifdef::env-github,rspecator-view[]

'''
== Implementation Specification
(visible only on this page)

=== Message

Increase the size of "YYY" or do not "MOVE" ("XXX"|this literal value) to it.


=== Parameters

.onlyLiteralValues
****

----
false
----

True to apply the rule only to literal values
****
.ignoredDataItemRegex
****

Regular expression describing sending fields to ignore
****


=== Highlighting

* primary ``++MOVE xx TO yy++``
* secondary1: xx
** message: xx is x_width
* secondary2: yy
** message: yy is y_width.


'''
== Comments And Links
(visible only on this page)

=== relates to: S3921

=== on 19 Sep 2014, 15:42:06 Freddy Mallet wrote:
@Ann, perhaps we could associate this rule to \http://cwe.mitre.org/data/definitions/704.html ? This is a bit controversial as CWE-704 is Weakness Class.

endif::env-github,rspecator-view[]
