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); 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. -- While a transcendent vocabulary is laudable, one must be eternally careful so that the calculated objective of communication does not become ensconced in obscurity. In other words, eschew obfuscation. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
