On 16/12/2014 9:58 PM, John McKown wrote:
On Tue, Dec 16, 2014 at 7:45 AM, David Crayford <[email protected]> wrote:
On 16/12/2014 9:32 PM, John McKown wrote:
On Tue, Dec 16, 2014 at 7:25 AM, David Crayford <[email protected]>
wrote:
Sorry to be critical but you really do need to check the return value
from
malloc() and realloc(). I would also replace the ascending goto with a
while loop. Other than that it looks good.
Not critical, helpful! I put in a check on the malloc(). It never
occurred
to me that the realloc() could fail because it is only used to shrink the
existing allocation. I guess that I thought that shrinking was always an
"in place" operation.
I'll fix that too.
I would have the client pass in a buffer and length and not do any heap
allocation. There should be a max length that can be specified in a #define
MAX_LRECL constant.
I guess, in that case, that the prototype would look something like:
void *vbsread(int fd, void *buffer, int buffer_length);
Well you need a to set the bounds for the buffer length for the client.
void *vbsread(int fd, void *buffer, size_t buffer_length);
char buffer[MAX_LRECL];
vbsread(fd,buffer,sizeof buffer)
Is a MAX_LRECL really needed? Is a z/OS VB record _ever_ greater than
32767 bytes? Yes, I can see how somebody could write a program which
creates a data set containing VBS segments which, combined, would exceed
that limit. But using "normal" z/OS facilities, it would be difficult. And
I'd bet that even the venerable DFSORT would cough up hair balls trying to
process it. I need to read up on LRI, I guess.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
