paulgboul...@aim.com (Paul Gilmartin) writes: > You, Lynn, and John G. are correct to distrust null-terminated strings.
re: http://www.garlic.com/~lynn/2012l.html#67 Strings (hijacked from: The IBM zEnterprise EC12 announcment) in lots of discussions about C language string&buffer conventions being one the primary sources of programming errors ... there were analogous with careful drivers never having accidents and therefor there are no need for bumpers, safety glass, crash zones, seatbelts, padded dashboards, airbags, etc. the more straight-forward analysis is that buffer length management is left to the programmer ... always having to manually manage whether the implicit length (of null terminated string) fits within target storage area. I've compared it to assembler language programming where a major manual effort on the programmer was managing register contents ... and mis-managed register contents has been major assembler programming error ... especially in complex programs with large number of code paths ... and at any particular point in execution ... did all possible execution paths correctly initialize registers. It turns out that one of the benifits attributed for moving to C-programming ... is it allows system level programming while alleviating manual effort of the programmer managing the register contents. However, it has trade-off the elimination of the manual register content management effort with the buffer length manual management effort. Long ago and far away (in the very earliest days of rexx before released to customers)... I wanted to demonstrate the power of REXX ... and selected IPCS ... which was a large, assembler implemented application. Objective was to completely re-implemented IPCS in REXX ... working half-time over 3month period ... with the new implementation having ten times the function and with ten times the performance (some coding slight of hand to make an application in REXX run ten times faster than corresponding application in assembler). I finished early ... so I started doing analysis of kinds of failures and their failure signatures ... developing an augmented library of IPCS procedures that could be automated to look for the various kinds of failure scenarios. Misc. past posts mentioning DUMPRX http://www.garlic.com/~lynn/submain.html#dumprx I had assumed that it would be released to customers as IPCS replacement ... which never happened for whatever reason ... although it eventually came to be used by all internal datacenters and nearly all customer support PSRs. I eventually managed to get approval for making presentation at user group meetings about how it was implemented ... and within a couple of months, similar implementations started to appear from other vendors. Two of the most common were 1) anomolous code path failure to establish register contents (required at later point) and 2) dangling buffer pointers (aka asynchronous operation using pointer to storage area that was no longer active ... the particular storage area no longer active and/or re-allocated for some other purpose). Most higher-level languages eliminate manual programmer effort in managing register contents. One of the characteristics claimed for languages like Java & LISP is having eliminated programmer manual managed storage ... no only doesn't have C-language buffer length like problems ... but also has eliminated dangling pointer problems. -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
