From Newsgroup: comp.lang.cobol

On Monday, May 14, 2018 at 10:09:36 AM UTC-5, Kellie Fitton wrote:

Hi Folks. It's me again.

Some programming languages such as C sharp for example, support
software engineering principles such as detection of attempts
to use uninitialized variables, and ensure programs with unsafe
code must have appropriate permission to run. So, I tested my
Net Express COBOL compiler on these basic programming principles.
I moved an alphabetic string variable to a numeric variable.
the compiler did not raise a flag. It simply compiled the code,
produced an executable program and ran it. Here are my questions:

1). Why the COBOL compiler does not raise a red flag when you move
an alphabetic string to a numeric variable?

2). Do other programming languages compilers raise a red flag when
an alphabetic string is moved to a numeric variable?

3). Why compilers are not designed to ensure the importance of
programmers productivity and to safe guard against such
flagrant, serious and naked software bugs?

Your feedback is very much appreciated.

COBOL - the elephant that can stand on its trunk...

Unisys OS2200 cobol compiler will issue a warning.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

On Tuesday, May 15, 2018 at 1:09:36 AM UTC+10, Kellie Fitton wrote:

Hi Folks. It's me again.

Some programming languages such as C sharp for example, support
software engineering principles such as detection of attempts
to use uninitialized variables, and ensure programs with unsafe
code must have appropriate permission to run. So, I tested my
Net Express COBOL compiler on these basic programming principles.
I moved an alphabetic string variable to a numeric variable.
the compiler did not raise a flag. It simply compiled the code,
produced an executable program and ran it. Here are my questions:

1). Why the COBOL compiler does not raise a red flag when you move
an alphabetic string to a numeric variable?

2). Do other programming languages compilers raise a red flag when
an alphabetic string is moved to a numeric variable?

Yes. PL/I does.

3). Why compilers are not designed to ensure the importance of
programmers productivity and to safe guard against such
flagrant, serious and naked software bugs?

Your feedback is very much appreciated.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

On Tuesday, May 15, 2018 at 2:13:18 AM UTC+10, Kerry Liles wrote:

On 5/14/2018 11:42 AM, Clark F Morris wrote:

On Mon, 14 May 2018 08:09:35 -0700 (PDT), Kellie Fitton
<[email protected]> wrote:

Some programming languages such as C sharp for example, support
software engineering principles such as detection of attempts
to use uninitialized variables, and ensure programs with unsafe
code must have appropriate permission to run. So, I tested my
Net Express COBOL compiler on these basic programming principles.
I moved an alphabetic string variable to a numeric variable.
the compiler did not raise a flag. It simply compiled the code,
produced an executable program and ran it. Here are my questions:

Which compiler? I am fairly certain that the IBM compilers would flag
a PIC X to PIC 9 MOVE and probably fail the compilation. I don't have
a system available to me to verify this.

Clark Morris

1). Why the COBOL compiler does not raise a red flag when you move
an alphabetic string to a numeric variable?

2). Do other programming languages compilers raise a red flag when
an alphabetic string is moved to a numeric variable?

3). Why compilers are not designed to ensure the importance of
programmers productivity and to safe guard against such
flagrant, serious and naked software bugs?

Your feedback is very much appreciated.




COBOL - the elephant that can stand on its trunk...

I just tested this on IBM COBOL FOR VSE/ESA 1.1.1

The compiler does not flag the move of PIC X to PIC 9. Here is a sample output I cobbled together to summarize what happens in a couple of cases:

SOURCE-FIELD 12345
DEST-FIELD 12345
SOURCE-FIELD ABCDE
DEST-FIELD ABCD5

Here is the code (at least relevant bits):

WORKING-STORAGE SECTION.

01 FILLER.
05 SOURCE-FIELD PIC X(5).
05 DEST-FIELD PIC 9(5).

PROCEDURE DIVISION.

0000-MAINLINE.
MOVE '12345' TO SOURCE-FIELD
MOVE SOURCE-FIELD TO DEST-FIELD
DISPLAY 'SOURCE-FIELD ' SOURCE-FIELD
DISPLAY ' DEST-FIELD ' DEST-FIELD
MOVE 'ABCDE' TO SOURCE-FIELD
MOVE SOURCE-FIELD TO DEST-FIELD
DISPLAY 'SOURCE-FIELD ' SOURCE-FIELD
DISPLAY ' DEST-FIELD ' DEST-FIELD
.

9000-END.
STOP RUN
.

I think the COBOL manuals explicitly state what happens in these mixed situations and indeed a LOT of old code is written to depend on that specific sort of behaviour...

I ran the same task in PL/I (the code follows, with results beneath):--

test: procedure options (main);

declare source_field pic 'xxxxx';
declare dest_field pic '99999';

source_field = '12345';
dest_field = source_field;
put (dest_field);

source_field = 'ABCDE';
dest_field = source_field;
put skip list (dest_field);
end test;

Output:

12345
IBM0032I ONCODE=0612 The CONVERSION condition was raised
because a conversion error occurred when converting from character
to arithmetic.
At offset +00000159 in procedure with entry TEST
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.cobol

On Tuesday, May 15, 2018 at 4:13:18 AM UTC+12, Kerry Liles wrote:

SOURCE-FIELD 12345
DEST-FIELD 12345
SOURCE-FIELD ABCDE
DEST-FIELD ABCD5

The reason that the last digit is modified to a 5 is that the high bits of the last byte are used to indicate the sign (unless sign separate is specified) and these bits would be cleared for a positive or unsigned move.


--- Synchronet 3.20a-Linux NewsLink 1.114