Over many years, I have brought up the C string problem. Both it's speed and safety. I developed some C macros which improve the situation, however I think that by simply introducing a new file type, say .VB like .EXE, many speed and safety issues can be corrected relatively simply, as well as reducing the electricity and cooling water needed to shunt 5 billion emails around the world each day.
The VB format would follow IBM's VB format. Thus the length of the record would precede the data, and allow records to be moved and copied without constantly searching for binary zeros, or carriage returns and line feeds. My tests have consistently shown that copying strings with C takes a minimum of about 2.5 times longer to copy C terminated strings. Often, the time is greater depending on the compiler and associated routines. I believe implementing such code would be relatively trivial. And I would also suggest the record length and blocksize be 4 bytes rather than 2 bytes. The open routines could look to see if the file or data set is .VB, and if so set a flag. When a GET or equivalent is issued, then it is a simple matter to read the block if necessary, and load the length of the record and issue an MVCL or equivalent on other machines. Gradually, C and C++ could be changed internally to follow the excellent PL/I practice of having the length of variable length strings at the front of the strings which means searching for string terminators is not necessary. Kind regards, and a Happy New Year to all, Clem Clarke PS: Some further information is at https://start.oscar-jol.com/fast-safe-c-strings Charles Mills kindly suggested that C++ was the answer. However, I think ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
