
Inline adoc files when they are included exactly once. Also fix language tags because this inlining gives us better information on what language the code is written in.
94 lines
3.0 KiB
Plaintext
94 lines
3.0 KiB
Plaintext
== Why is this an issue?
|
|
|
|
An alphanumeric value should not be moved to a numeric field. Because alphanumeric values are stored differently than numeric values, simply moving the bits from one field to the other will yield strange results at best, and crashes at worst.
|
|
|
|
|
|
Instead, ``++NUMVAL++`` should be used to explicitly convert the alphanumeric value to a numeric one.
|
|
|
|
|
|
=== Noncompliant code example
|
|
|
|
[source,cobol]
|
|
----
|
|
01 MY-STR PIC X(3) VALUE SPACES.
|
|
01 MY-NUM PIC 9(3) VALUE ZEROES.
|
|
*> ...
|
|
MOVE '1' TO MY-STR
|
|
MOVE MY-STR TO MY-NUM *> Noncompliant
|
|
----
|
|
|
|
|
|
=== Compliant solution
|
|
|
|
[source,cobol]
|
|
----
|
|
01 MY-STR PIC X(3) VALUE SPACES.
|
|
01 MY-NUM PIC 9(3) VALUE ZEROES.
|
|
*> ...
|
|
MOVE '1' TO MY-STR
|
|
COMPUTE MY-NUM = FUNCTION NUMVAL(MY-STR)
|
|
----
|
|
|
|
or
|
|
|
|
|
|
[source,cobol]
|
|
----
|
|
01 MY-STR PIC X(3) VALUE SPACES.
|
|
01 MY-STR-RED REDEFINES MY-STR PIC 9(3).
|
|
01 MY-NUM PIC 9(3) VALUE ZEROES.
|
|
*> ...
|
|
IF MY-STR NUMERIC
|
|
MOVE MY-STR-RED TO MY-NUM
|
|
END-IF
|
|
----
|
|
|
|
|
|
== Resources
|
|
|
|
* https://cwe.mitre.org/data/definitions/704[MITRE, CWE-704] - Incorrect Type Conversion or Cast
|
|
|
|
|
|
ifdef::env-github,rspecator-view[]
|
|
|
|
'''
|
|
== Implementation Specification
|
|
(visible only on this page)
|
|
|
|
=== Message
|
|
|
|
"XXX" is a numeric field; "YYY" cannot be safely moved to it.
|
|
|
|
|
|
'''
|
|
== Comments And Links
|
|
(visible only on this page)
|
|
|
|
=== on 25 Aug 2014, 20:06:14 Ann Campbell wrote:
|
|
\[~pierre-yves.nicolas] according to \http://www.csis.ul.ie/cobol/course/DataDeclaration.htm there are 3 types: numeric, alphanumeric, alphabetic. Should this rule be expanded to also cover alphabetic -> numeric?
|
|
|
|
=== on 25 Aug 2014, 20:07:35 Ann Campbell wrote:
|
|
FYI, this is an example of a rule implementing a Class - the rule is indeed an example of "Incorrect Type Conversion or Cast" but none of the existing child variants or bases map correctly.
|
|
|
|
=== on 25 Aug 2014, 21:07:20 Freddy Mallet wrote:
|
|
Indeed [~ann.campbell.2]
|
|
|
|
=== on 26 Aug 2014, 15:46:57 Pierre-Yves Nicolas wrote:
|
|
See \http://www-01.ibm.com/support/knowledgecenter/SS6SG3_5.1.0/com.ibm.cobol511.ent.doc/PGandLR/rlpsmovea2.html
|
|
|
|
I don't know whether this rule should be expanded to also cover also cover alphabetic -> numeric.
|
|
|
|
According to IBM reference, alphabetic -> numeric is invalid: I suppose that the compiler should generate an error.
|
|
|
|
But alphanumeric -> numeric is valid with the following note: "Figurative constants and alphanumeric literals must consist only of numeric characters and will be treated as numeric integer fields." My understanding is that the MOVE can lead to the expected result when that condition is fulfilled, but it is very easy to make a mistake.
|
|
|
|
|
|
|
|
=== on 26 Aug 2014, 16:15:51 Ann Campbell wrote:
|
|
Thanks [~pierre-yves.nicolas]. I'll leave it as-is, then.
|
|
|
|
=== on 19 Sep 2014, 11:30:21 Freddy Mallet wrote:
|
|
@Ann, I would associate this rule to the SQALE sub-characteristic "Instruction Related Reliability"
|
|
|
|
endif::env-github,rspecator-view[]
|