Cobol program crashes sorting an empty array. Bug or other ?

[Thomas Ritter]

A COBOL program crashes when trying to sort an empty array. The programmer has the view this is a complier problem and not a programming problem.

Here is a reproducer and the accompanying error message.

identification division.
program-id. testsort2.
author. Programmer.
date-compiled.

environment division.
configuration section.
source-computer. vax.
object-computer. vax.
special-names.
data division.

working-storage section.
01 num_sig_dates pic s9(9) comp value 0.
01 sig_date_tbl.
03 sig_date occurs 0 to 100 times depending on num_sig_dates pic x(50).

procedure division.
start-up.
sort sig_date
on ascending sig_date.

stop run.



$ COBOL/CHECK=(ALL,NOPERFORM,NODUPLICATE)/NOALIGN TESTSORT
$ link testsort

$ r testsort
%COB-F-SUBSCRIPT, Subscript out of bounds
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
DEC$COBRTL 0 0000000000000ECC 000000007C322ECC
DEC$COBRTL 0 000000000003603C 000000007C35803C
----- above condition handler called with exception 0000056C:
%SYSTEM-F-RANGEERR, range error, PC=0000000000030118, PS=0000001B
----- end of exception message
0 FFFFFFFF8009C09C FFFFFFFF8009C09C
TESTSORT TESTSORT2 TESTSORT2 20 0000000000000118 0000000000030118
TESTSORT 0 00000000000304A0 00000000000304A0
0 FFFFFFFF80269ED4 FFFFFFFF80269ED4



What is your opinion? Complier problem or programming bug?

[John Gillings]

Thomas,

I'd say programming bug. Two reasons...

1) By definition a 0 length array has no valid subscripts so any attempt to access the array should fail with subscript out of bounds. What else could an access attempt return?

2) The only other possible result from the SORT operation would be returning silently. That could be obscuring a logic error in the program. Any programmer who WANTS that behaviour can easily conditionalise it with "IF num_sig_dates GREATER THAN ZERO THEN".

On the other hand, this kind of edge condition is always debatable. My preference is for the onus to be on the programmer to be very explicit about how it should be handled. Anything even slightly questionable should be complained about. Compilers "being nice", and making assumptions about how non-sensical requests should be handled is a source of many bugs!

[John Gillings]

Thomas,

Forgot to add... if you want an authoritative answer, please log a case with your local customer support centre ;-)

[Thomas Ritter]

The clue is the COBOL/CHECK=ALL switch. I will log a call.

If we compile without CHECK=ALL there is no stack dump. However the programmers insist on using CHECK=ALL to check for other out of bound problems.

Thomas

[John Reagan]

Well, the manual isn't too clear on whether a zero length table is legal. I'll check more on it when I return (I'm leaving on vacation on Wednesday and won't return until after the first of the year). In the meantime, "don't do that".

John
COBOL Project Leader

[Thomas Ritter]

This is the standard way Cobol is complied

COBOL/CHECK=(ALL,NOPERFORM,NODUPLICATE)/NOALIGN TESTSORT

[Doug Phillips]

I'd call it a bug in the cobol sort. The sort succeeded; it was give nothing to sort and it returned nothing sorted. If it is given 1 thing to sort does it error out, even though it does no work? DCL sort doesn't error out when given an empty input file; it returns an empty output file, not an error.

[Doug Phillips]

To appease my unnamed, shy but vocal, pedantic friends:-) Of course, I meant: "The sort [should have] succeeded; it was given nothing to sort and it [should] return nothing sorted [rather than error out, as it did].


1) By definition a 0 length array has no valid subscripts so any attempt to access the array should fail with subscript out of bounds. What else could an access attempt return?


But, 0 is a valid run-time array length value. We load an array with a variable & unknown number of elements so we can sort it. In this case, we loaded it with 0 elements. That the language-provided sort routine subscripted using that 0, -F-ailed, and stack dumped can't be considered the desired behavior.


2) The only other possible result from the SORT operation would be returning silently.


Yes. That would be the correct result.


That could be obscuring a logic error in the program. Any programmer who WANTS that behaviour can easily conditionalise it with "IF num_sig_dates GREATER THAN ZERO THEN".


The caller logic probably will do something "special" if nothing is loaded into the array, or maybe the program will fail someplace else. It's not the sort routine's place to worry about that.

The programmer, *might* use "IF num_sig_dates GREATER THAN ONE THEN" to conditionalize the sort, but it seems reasonable that the sort routine *should* check whether the array length is greater than one before doing anything else.


On the other hand, this kind of edge condition is always debatable.


There can be no debate that it's an out-of-bounds condition error, but the error is within the sort logic and not the calling program. Zero is within the bounds of possible array lengths.

Like the C buffer overflow bug, which has been similarly debated, the solution is to correct it "internally" at the point of failure. (I'll probably be sorry I brought that up!;-)