On Wed, May 31, 2017 at 4:43 PM, Charles Mills <[email protected]> wrote:

> I agree that is a likely to astonish but it is standard COBOL, no? No
> different than if you did MOVE 'GOODBYE' TO SOME-VAR. You'd end up with
> less than you might have expected.
>

​Yes, it is standard. In fact, I wish the compiler would flag the MOVE with
at least a (suppressible?) warning level message.​ The main reason that I
consider it worse than usual is the fact that the ending x'00' is not
explicit in the constant. So a COBOL programmer who is not used to this
"new" facility is not as likely to see a problem. Also, s?he is likely to
count the number of characters in the string and compare it directly with
the value in the PIC. I'm more worried about a programmer who sees
something like:

77 SOME-VAR PIC X(6).
77 VAR-LENGTH PIC S9(9) BINARY.

MOVE Z'HOUSE' TO SOME-VAR.
CALL 'strlen' USING SOME-VAR RETURNING VAR-LENGTH.

Who says to themselves: "I need to make that plural. Well, HOUSES is 6
characters. That will fit in the existing allocation, so I'm good". (i.e.
ignorant or in a hurry) The original program gets back a 5. After the
change to HOUSES, the program gets back a number equal or greater than 6,
depending on what comes after in memory. The COBOL program now has insane
data. Also, it might be that the C routine does something which could
possibly get an S0C4 abend as it "goes wild". Heck, even strlen() might get
an S0C4 as it runs amok. I may be a bit disparaging of COBOL programmers,
but I've seen some really bad COBOL code. A good IDE would be helpful. That
is NOT the editor in ISPF!

Perhaps what I'm getting at is that mixing COBOL and C is more dangerous
than just plain COBOL. Of course, I'm well aware of the "dangers" of index
out of bound or a bad reference modification. Maybe I'm just "death" on
"buffer overflows" after reading how they are often used in malware. I
_love_ PL/I!


>
> Charles
>
>
>

-- 
Windows. A funny name for a operating system that doesn't let you see
anything.

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to