Re: Strings (hijacked from: The IBM zEnterprise EC12 announcment)
On Tue, Sep 4, 2012 at 7:03 PM, Paul Gilmartin paulgboul...@aim.com wrote: snip. You, Lynn, and John G. are correct to distrust null-terminated strings. But if you write in C, you are pretty much stuck with them since the library uses them. Call it distrust if you want, but they work fine with careful coding practices (which many programmers implement in C macros or C++ inline functions). Modern C/C++ compilers treat several of the str* functions as inlined instrinsics. For example, the z/OS C compiler typically generates an inline MVST instruction for strncpy(). Kirk Wolf Dovetailed Technologies http://dovetail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Strings (hijacked from: The IBM zEnterprise EC12 announcment)
Good point. Many of you out there seem to dislike C for such reasons like that discussed here: you have to take more responsibility for manageing the lengths of the used buffers etc. - but the same people often like ASSEMBLER, where the chance to put errors in your program is much higher. My opinion is: if you handle C carefully and you know about its pitfalls, it can be a really great implementation language for software that is targetted not far from the operating system, that is, tools, compilers, parsers, db systems, embedded applications etc. - but it works also for commercial or scientific application systems. One of its biggests strengths is portability. I work with C now for almost 20 years (and with PL/1, ASSEMBLER, Fortran, Pascal, even COBOL, REXX etc.), and I like C very much. It is possible to write secure programs in C, if you follow some rules, for example when using string functions. C++ is another thing - I would strongly recommend to make a difference. There are too much strange things happening under the cover, and I don't like it, if the programming language does things that I'm not aware of. Kind regards Bernd Am 05.09.2012 17:10, schrieb Anne Lynn Wheeler: 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 stringbuffer 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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Strings (hijacked from: The IBM zEnterprise EC12 announcment)
If we had the C compiler, I would use it. Of course, I wouldn't have learned how to create DLLs use LE enabled HLASM, either. Yes, I've done that. As far as compiled HLLs are concerned, I've always loved PL/I. I would probably like the PL/X (or whatever) that IBM uses for much of their software development too. I use C, but not C++, on Linux/Intel some. But I prefer Perl because I'm generally doing ad hoc reports. And Perl is, for me, very nice for that. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bernd Oppolzer Sent: Wednesday, September 05, 2012 10:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Strings (hijacked from: The IBM zEnterprise EC12 announcment) Good point. Many of you out there seem to dislike C for such reasons like that discussed here: you have to take more responsibility for manageing the lengths of the used buffers etc. - but the same people often like ASSEMBLER, where the chance to put errors in your program is much higher. My opinion is: if you handle C carefully and you know about its pitfalls, it can be a really great implementation language for software that is targetted not far from the operating system, that is, tools, compilers, parsers, db systems, embedded applications etc. - but it works also for commercial or scientific application systems. One of its biggests strengths is portability. I work with C now for almost 20 years (and with PL/1, ASSEMBLER, Fortran, Pascal, even COBOL, REXX etc.), and I like C very much. It is possible to write secure programs in C, if you follow some rules, for example when using string functions. C++ is another thing - I would strongly recommend to make a difference. There are too much strange things happening under the cover, and I don't like it, if the programming language does things that I'm not aware of. Kind regards Bernd Am 05.09.2012 17:10, schrieb Anne Lynn Wheeler: 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 stringbuffer 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
Re: Strings (hijacked from: The IBM zEnterprise EC12 announcment)
Well, that's the choice, isn't it? Either you do everything yourself, or the compiler does things for you. I really like C++. It provides a framework for organizing a large project that is invaluable IMHO. If you just evaluate C++ as is it a better way to write Hello World? then the answer is no -- it's just a more complex way. But for serious product development I find it invaluable. It also brings along the Standard Template Library. Everyone is fussing about null-terminated char[] strings. Well, the problem has been solved: it's called the STL std::string -- a safe, variable-length (up to 2-gig) automatic character string with built-in functions like ::compare() and ::append() that interoperates with old stuff that requires a char[]-type string. Speaking of the problems of char[] strings, no one has mentioned char a[] = foo; char b[] = bar; if (a b) printf(this printf will never happen\n); (Well, probably never happen. The result is implementation-dependent.) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bernd Oppolzer Sent: Wednesday, September 05, 2012 8:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Strings (hijacked from: The IBM zEnterprise EC12 announcment) Good point. Many of you out there seem to dislike C for such reasons like that discussed here: you have to take more responsibility for manageing the lengths of the used buffers etc. - but the same people often like ASSEMBLER, where the chance to put errors in your program is much higher. My opinion is: if you handle C carefully and you know about its pitfalls, it can be a really great implementation language for software that is targetted not far from the operating system, that is, tools, compilers, parsers, db systems, embedded applications etc. - but it works also for commercial or scientific application systems. One of its biggests strengths is portability. I work with C now for almost 20 years (and with PL/1, ASSEMBLER, Fortran, Pascal, even COBOL, REXX etc.), and I like C very much. It is possible to write secure programs in C, if you follow some rules, for example when using string functions. C++ is another thing - I would strongly recommend to make a difference. There are too much strange things happening under the cover, and I don't like it, if the programming language does things that I'm not aware of. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Strings (hijacked from: The IBM zEnterprise EC12 announcment)
Rexx is so magical there is no real reason it could not support Substr(a,3,1) = 'x' and actually be doing a = Substr(a,1,2) || 'x' || Substr(a,4) under the covers. Even, for that matter, Substr(a,3,1) = 'xyz' or Substr(a,3,3) = 'x' Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Wednesday, September 05, 2012 11:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Strings (hijacked from: The IBM zEnterprise EC12 announcment) On 5 September 2012 13:26, Scott Ford scott_j_f...@yahoo.com wrote: I find it interesting that in REXX , its really easy to handle strings ..in fact to me pretty simple. Maybe because I very very familar with Rexx since it came out. Why cant C and C++ be this way without going thru all the gyrations. In REXX strings are unchangeable (immutable, in Java-speak), though REXX makes this less explicit than Java. You can't change a string; the best you can do is create a new one. Of course how this is done under the covers is another matter, and the compiler/interpreter may well decide to update the string in place under appropriate circumstances. Immutable strings have some consequences for both performance and data security, and there are times when it's annoying not to be able to do something like Substr(a,3,1) = 'x', rather than a = Substr(a,1,2) || 'x' || Substr(a,4). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Strings (hijacked from: The IBM zEnterprise EC12 announcment)
I have to give Mike Cowlishaw a lot of credit Rexx works well Scott ford www.identityforge.com On Sep 5, 2012, at 3:51 PM, Charles Mills charl...@mcn.org wrote: Rexx is so magical there is no real reason it could not support Substr(a,3,1) = 'x' and actually be doing a = Substr(a,1,2) || 'x' || Substr(a,4) under the covers. Even, for that matter, Substr(a,3,1) = 'xyz' or Substr(a,3,3) = 'x' Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Wednesday, September 05, 2012 11:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Strings (hijacked from: The IBM zEnterprise EC12 announcment) On 5 September 2012 13:26, Scott Ford scott_j_f...@yahoo.com wrote: I find it interesting that in REXX , its really easy to handle strings ..in fact to me pretty simple. Maybe because I very very familar with Rexx since it came out. Why cant C and C++ be this way without going thru all the gyrations. In REXX strings are unchangeable (immutable, in Java-speak), though REXX makes this less explicit than Java. You can't change a string; the best you can do is create a new one. Of course how this is done under the covers is another matter, and the compiler/interpreter may well decide to update the string in place under appropriate circumstances. Immutable strings have some consequences for both performance and data security, and there are times when it's annoying not to be able to do something like Substr(a,3,1) = 'x', rather than a = Substr(a,1,2) || 'x' || Substr(a,4). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Strings (hijacked from: The IBM zEnterprise EC12 announcment)
On 5 September 2012 15:51, Charles Mills charl...@mcn.org wrote: Rexx is so magical there is no real reason it could not support Substr(a,3,1) = 'x' and actually be doing a = Substr(a,1,2) || 'x' || Substr(a,4) under the covers. Even, for that matter, Substr(a,3,1) = 'xyz' or Substr(a,3,3) = 'x' Right - and that's because the process is unobservable because there is nothing like an Addr(a) that provides a reference, loosely speaking, to a. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Strings (hijacked from: The IBM zEnterprise EC12 announcment)
On Wed, 5 Sep 2012 18:02:51 -0400, Tony Harminc wrote: On 5 September 2012 15:51, Charles Mills charl...@mcn.org wrote: Rexx is so magical there is no real reason it could not support Substr(a,3,1) = 'x' and actually be doing a = Substr(a,1,2) || 'x' || Substr(a,4) under the covers. Even, for that matter, Substr(a,3,1) = 'xyz' or Substr(a,3,3) = 'x' Right - and that's because the process is unobservable because there is nothing like an Addr(a) that provides a reference, loosely speaking, to a. But consider the effects of storage() or of user-written function packages. It would be easy enough to code one that returns as a numeric string the address of one of its arguments. Reportedly MFC deprecated the similar suggestion of allowing expressions in compound symbol tails, partly because the lexical space is already so crowded (A.(2+2) is a valid function call); partly for performance reasons; and partly because of the complexity in recognizing assignment instructions it would introduce. Consider: Substr( a, F( V ), I=J+1 ) = X ... which has function calls and relational expressions on the left of an assignment. I know; other languages do it; MFC didn't believe Rexx needed to. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Strings (hijacked from: The IBM zEnterprise EC12 announcment)
It would be easy enough to code one that returns as a numeric string the address of one of its arguments. My recollection is that when calling assembler from Rexx you get the address of a copy of the string data, not the address of whatever internal control block represents a variable in Rexx. You can modify it all you want but it's a copy of the data, not Rexx's data and the address is meaningless once you return to Rexx. AFAIR you get one of those VM-style PLIST (is that the right term?) parameters: word 1 = address, word 2 = length, x'' = end of list. There is a library function to modify a Rexx variable from assembler, but it is very sandboxed. Reportedly MFC deprecated the similar suggestion NO complaints about MFC. Rexx is an awesome accomplishment. Too bad it is not more widely accepted, outside of the mainframe world. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, September 05, 2012 3:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Strings (hijacked from: The IBM zEnterprise EC12 announcment) On Wed, 5 Sep 2012 18:02:51 -0400, Tony Harminc wrote: On 5 September 2012 15:51, Charles Mills charl...@mcn.org wrote: Rexx is so magical there is no real reason it could not support Substr(a,3,1) = 'x' and actually be doing a = Substr(a,1,2) || 'x' || Substr(a,4) under the covers. Even, for that matter, Substr(a,3,1) = 'xyz' or Substr(a,3,3) = 'x' Right - and that's because the process is unobservable because there is nothing like an Addr(a) that provides a reference, loosely speaking, to a. But consider the effects of storage() or of user-written function packages. It would be easy enough to code one that returns as a numeric string the address of one of its arguments. Reportedly MFC deprecated the similar suggestion of allowing expressions in compound symbol tails, partly because the lexical space is already so crowded (A.(2+2) is a valid function call); partly for performance reasons; and partly because of the complexity in recognizing assignment instructions it would introduce. Consider: Substr( a, F( V ), I=J+1 ) = X ... which has function calls and relational expressions on the left of an assignment. I know; other languages do it; MFC didn't believe Rexx needed to. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Strings (hijacked from: The IBM zEnterprise EC12 announcment)
On Wed, 5 Sep 2012 15:41:15 -0700, Charles Mills wrote: It would be easy enough to code one that returns as a numeric string the address of one of its arguments. My recollection is that when calling assembler from Rexx you get the address of a copy of the string data, not the address of whatever internal control block represents a variable in Rexx. You can modify it all you want but it's a copy of the data, not Rexx's data and the address is meaningless once you return to Rexx. However, ADDRESS LINKPGM (and I believe ADDRESS LINKMVS) allow the called program to modify the Rexx variables passed as arguments, whether via a copy or directly. See SYS1.SAMPLIB(CSFTEST) for an example. AFAIR you get one of those VM-style PLIST (is that the right term?) parameters: word 1 = address, word 2 = length, x'' = end of list. LINKPGM, et al. pass OS CALL-style PLISTs. There is a library function to modify a Rexx variable from assembler, but it is very sandboxed. Is this IRXEXCOM, IIRC? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Strings (hijacked from: The IBM zEnterprise EC12 announcment)
ADDRESS LINKPGM ... allow the called program to modify the Rexx variables passed as arguments Could be -- but you still get the *string data*, right, not the address of whatever internal control block represents a variable inside Rexx? My *guess* would be that if you can indeed modify the data then the modification happens via the IRXEXCOM-ing back of the data into Rexx. Is this IRXEXCOM Sounds right. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, September 05, 2012 4:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Strings (hijacked from: The IBM zEnterprise EC12 announcment) On Wed, 5 Sep 2012 15:41:15 -0700, Charles Mills wrote: It would be easy enough to code one that returns as a numeric string the address of one of its arguments. My recollection is that when calling assembler from Rexx you get the address of a copy of the string data, not the address of whatever internal control block represents a variable in Rexx. You can modify it all you want but it's a copy of the data, not Rexx's data and the address is meaningless once you return to Rexx. However, ADDRESS LINKPGM (and I believe ADDRESS LINKMVS) allow the called program to modify the Rexx variables passed as arguments, whether via a copy or directly. See SYS1.SAMPLIB(CSFTEST) for an example. AFAIR you get one of those VM-style PLIST (is that the right term?) parameters: word 1 = address, word 2 = length, x'' = end of list. LINKPGM, et al. pass OS CALL-style PLISTs. There is a library function to modify a Rexx variable from assembler, but it is very sandboxed. Is this IRXEXCOM, IIRC? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Strings (hijacked from: The IBM zEnterprise EC12 announcment)
On Wed, 5 Sep 2012 16:18:07 -0700, Charles Mills wrote: ADDRESS LINKPGM ... allow the called program to modify the Rexx variables passed as arguments Could be -- but you still get the *string data*, right, not the address of whatever internal control block represents a variable inside Rexx? My *guess* would be that if you can indeed modify the data then the modification happens via the IRXEXCOM-ing back of the data into Rexx. All which bodes ill for one of my wishes: a concurrent ATTACH facility. But it could still happen if the ATTACH interface obtained storage for a communication area and passed its address back to Rexx where an EXEC could manipulate it with the STORAGE() function. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Strings (hijacked from: The IBM zEnterprise EC12 announcment)
What Open Object Rexx are strings handled the same way ? Scott ford www.identityforge.com On Sep 5, 2012, at 7:18 PM, Charles Mills charl...@mcn.org wrote: ADDRESS LINKPGM ... allow the called program to modify the Rexx variables passed as arguments Could be -- but you still get the *string data*, right, not the address of whatever internal control block represents a variable inside Rexx? My *guess* would be that if you can indeed modify the data then the modification happens via the IRXEXCOM-ing back of the data into Rexx. Is this IRXEXCOM Sounds right. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, September 05, 2012 4:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Strings (hijacked from: The IBM zEnterprise EC12 announcment) On Wed, 5 Sep 2012 15:41:15 -0700, Charles Mills wrote: It would be easy enough to code one that returns as a numeric string the address of one of its arguments. My recollection is that when calling assembler from Rexx you get the address of a copy of the string data, not the address of whatever internal control block represents a variable in Rexx. You can modify it all you want but it's a copy of the data, not Rexx's data and the address is meaningless once you return to Rexx. However, ADDRESS LINKPGM (and I believe ADDRESS LINKMVS) allow the called program to modify the Rexx variables passed as arguments, whether via a copy or directly. See SYS1.SAMPLIB(CSFTEST) for an example. AFAIR you get one of those VM-style PLIST (is that the right term?) parameters: word 1 = address, word 2 = length, x'' = end of list. LINKPGM, et al. pass OS CALL-style PLISTs. There is a library function to modify a Rexx variable from assembler, but it is very sandboxed. Is this IRXEXCOM, IIRC? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Strings (hijacked from: The IBM zEnterprise EC12 announcment)
In 3240638450612647.wa.paulgboulderaim@listserv.ua.edu, on
09/05/2012
at 06:09 PM, Paul Gilmartin paulgboul...@aim.com said:
Is this IRXEXCOM, IIRC?
From the GI:
3.1.3.2 TSO/E REXX programming services
IRXEXCOM - Variable Access
The IRXEXCOM variable access routine lets unauthorized
commands and programs access and manipulate REXX variables.
Details are in z/OS TSO/E REXX Reference, SA22-7790-08
12.4 Variable access routine - IRXEXCOM
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
Atid/2http://patriot.net/~shmuel
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Strings (hijacked from: The IBM zEnterprise EC12 announcment)
If you construct an array by initializing it element by element you get an array, one that is not nul-delimited or 'of conceptually unlimited length', whatever that may mean. If you construct a string by initializing a character array with a string, you get a nul-delimited string implemented under the hood|bonnet as an array. String manipulation is flawed in C, problematic because the view of a string as an array of single characters is yet another example of too much hacking about with Ockham's razor. --jg On 9/4/12, Paul Gilmartin paulgboul...@aim.com wrote: On Tue, 4 Sep 2012 07:57:17 -0700, Charles Mills wrote: Just because you *can* create a malformed string with no delimiter does not mean that my statement about proper C behavior is untrue. And here, I find myself in rare agreement with John G.'s view (if I understand correctly). A char[] containing no \0 is a perfectly valid array of char. It is not a string, by C's convention, and there is no requirement that a char[] represent a string. On Tue, 4 Sep 2012 06:22:43 -0700, Charles Mills wrote: char[] delimits strings with '\0' in every implementation in the world, I think. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Strings (hijacked from: The IBM zEnterprise EC12 announcment)
paulgboul...@aim.com (Paul Gilmartin) writes: And here, I find myself in rare agreement with John G.'s view (if I understand correctly). A char[] containing no \0 is a perfectly valid array of char. It is not a string, by C's convention, and there is no requirement that a char[] represent a string. in the 90s, C-language string related buffer exploits were top of internet attacks. I've been on campaign about this for long time. lots of past posts http://www.garlic.com/~lynn/subintegrity.html#overflow the mainframe TCP/IP stack from the 80s was done in vs/pascal and had none of the C-language buffer length related problems. The implementation had a few other performance issues ... getting 44kbytes/sec thruput using nearly whole 3090 processor. I did the changes for RFC1044 support and in some performance tests at cray research got channel media thruput between 4341 and cray using only modest amount of 4341 processor http://www.garlic.com/~lynn/subnetwork.html#1044 also, air force performance evaluation of Multics (implemented in PLI) noted that it had no buffer length related problems. Old post about IBM Research update of the Air Force Multics study http://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation This is post about analysis I did of the Mitre CVE exploit database ... looking for ways to improve my merged security taxonomy glossary (and how you do you structure thinking about security) http://www.garlic.com/~lynn/2004e.html#43 security taxonomy and CVE I suggested to mitre that they start requiring reports to have a little more structured information since they were quite free-form at the time. Their response was that they were lucky to get reports in any form at all ... adding structure form requirements afraid some people would just not do the report (although they have since started advising about more structure in the reports). Later , NIST came out with analysis that exploits were approx. nearly 1/3rd buffer related, 1/3rd automated script execution, and 1/3rd social engineering (with various other misc.). I periodically mention this meeting in ellison's conference room http://www.garlic.com/~lynn/95.html#13 a couple weeks later cluster scaleup is transferred and we are told we couldn't work on anything with more than four processors ... motivating us to leave. A couple of the other people mentioned in the meeting, later leave and show up at small client/server startup responsible for something called commerce server. We get brought in as consultants because they want to do payment transactions on the server, the startup had also invented this technology called SLL they want to use, the result is now frequently called electronic commerce. Part of the deployment for electronic commerce was developing something called a payment gateway ... sits on the internet and handles transactions between webservers and the payment networks (we periodically refer to it as the original SOA). misc. past posts mentioning payment gateway http://www.garlic.com/~lynn/subnetwork.html#gateway Part of protection for the payment gateways there are multiple layers of firewalls and other kinds of filters. A common internet attack is long strings ... attempting to leverage buffer-overflow vulnerabilities found in about anything implemented in C-language ... so part of the intermediate security layers are checks for excessive long strings. We also have do do audits/reviews of SSL, digital certificates, certificate issuing authorities, etc ... and come up with some requirements about how things are deployed. Almost immediately the requirements are violated and we start referring to it as comfort security (aka security that provides feeling of comfort to all the users). -- 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
Re: Strings (hijacked from: The IBM zEnterprise EC12 announcment)
I have had to move a string type field like a parameter to a field like this, Jobn char[40]; memset(Jobn,'0',sizeof(Jobn)); strcpy(Jobn,x); Otherwise strcmp fails, where x is the parameter string Scott ford www.identityforge.com On Sep 4, 2012, at 1:05 PM, retired mainframer retired-mainfra...@q.com wrote: The construct char x[3] = ABC; will legally initialize an array of char without adding the '\0'. The only restriction is that this is not a string. :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of John Gilmore :: Sent: Tuesday, September 04, 2012 9:02 AM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Re: Strings (hijacked from: The IBM zEnterprise EC12 :: announcment) :: :: If you construct an array by initializing it element by element you :: get an array, one that is not nul-delimited or 'of conceptually :: unlimited length', whatever that may mean. :: :: If you construct a string by initializing a character array with a :: string, you get a nul-delimited string implemented under the :: hood|bonnet as an array. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Strings (hijacked from: The IBM zEnterprise EC12 announcment)
On Tue, Sep 4, 2012 at 12:03 PM, Scott Ford scott_j_f...@yahoo.com wrote: I have had to move a string type field like a parameter to a field like this, Jobn char[40]; memset(Jobn,'0',sizeof(Jobn)); strcpy(Jobn,x); Please post additional code and the precise contents of x. Please put the contents in hex format so it can be appropriately evaluated. That is to say if the ebcidic is SCOTT1, the hex would be x'E2C3D6E3E3F100'. There is insufficient information to provide an accurate answer. The memset shown above is not needed. strcpy copies to the dest from the source starting at the left most byte of the dest until a binary zero is encountered in the source field. The binary zero in the source field is copied to the destination field. This can (and does) cause buffer overflow if not properly managed. Otherwise strcmp fails, where x is the parameter string Scott ford www.identityforge.com On Sep 4, 2012, at 1:05 PM, retired mainframer retired-mainfra...@q.com wrote: The construct char x[3] = ABC; will legally initialize an array of char without adding the '\0'. The only restriction is that this is not a string. :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of John Gilmore :: Sent: Tuesday, September 04, 2012 9:02 AM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Re: Strings (hijacked from: The IBM zEnterprise EC12 :: announcment) :: :: If you construct an array by initializing it element by element you :: get an array, one that is not nul-delimited or 'of conceptually :: unlimited length', whatever that may mean. :: :: If you construct a string by initializing a character array with a :: string, you get a nul-delimited string implemented under the :: hood|bonnet as an array. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Strings (hijacked from: The IBM zEnterprise EC12 announcment)
I assume you meant '\0' and not '0'. Unless Jobn has been assigned a string previously, strcmp should fail. (Actually it would invoke undefined behavior.) strcpy does not care about the previous contents of the destination. (strcat does but that is a different function.) If the length of x plus the terminating nul fits in Jobn, strcpy will replace as much of the original contents as needed and will insure that it is properly terminated. The remaining portion of Jobn will be unchanged. Your memset serves no apparent purpose. :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of Scott Ford :: Sent: Tuesday, September 04, 2012 12:04 PM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Re: Strings (hijacked from: The IBM zEnterprise EC12 :: announcment) :: :: I have had to move a string type field like a parameter to a field like :: this, :: :: Jobn char[40]; :: :: memset(Jobn,'0',sizeof(Jobn)); :: strcpy(Jobn,x); :: :: Otherwise strcmp fails, where x is the parameter string :: :: Scott ford :: www.identityforge.com :: :: On Sep 4, 2012, at 1:05 PM, retired mainframer retired- :: mainfra...@q.com wrote: :: :: The construct :: char x[3] = ABC; :: will legally initialize an array of char without adding the '\0'. The :: only :: restriction is that this is not a string. :: :: :: -Original Message- :: :: From: IBM Mainframe Discussion List [mailto:IBM- :: m...@listserv.ua.edu] On :: :: Behalf Of John Gilmore :: :: Sent: Tuesday, September 04, 2012 9:02 AM :: :: To: IBM-MAIN@LISTSERV.UA.EDU :: :: Subject: Re: Strings (hijacked from: The IBM zEnterprise EC12 :: :: announcment) :: :: :: :: If you construct an array by initializing it element by element :: you :: :: get an array, one that is not nul-delimited or 'of conceptually :: :: unlimited length', whatever that may mean. :: :: :: :: If you construct a string by initializing a character array with a :: :: string, you get a nul-delimited string implemented under the :: :: hood|bonnet as an array. :: :: -- :: For IBM-MAIN subscribe / signoff / archive access instructions, :: send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN :: :: -- :: For IBM-MAIN subscribe / signoff / archive access instructions, :: send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Strings (hijacked from: The IBM zEnterprise EC12 announcment)
You absolutely should not have to do that. If you do then it is a reportable and serious bug. strcpy() is utterly documented as setting the terminating null. memset(Jobn,'0',sizeof(Jobn)); Assume you mean memset(Jobn,'\0',sizeof(Jobn)); Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Scott Ford Sent: Tuesday, September 04, 2012 12:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Strings (hijacked from: The IBM zEnterprise EC12 announcment) I have had to move a string type field like a parameter to a field like this, Jobn char[40]; memset(Jobn,'0',sizeof(Jobn)); strcpy(Jobn,x); Otherwise strcmp fails, where x is the parameter string -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Strings (hijacked from: The IBM zEnterprise EC12 announcment)
On Tue, 4 Sep 2012 14:32:12 -0500, Kirk Wolf wrote: (BTW - strncpy() also zeros bytes after the terminator, if necessary) For more information, see: http://www.courtesan.com/todd/papers/strlcpy.html under Common Misconceptions There's no discernible date of publication of that paper save for some interior references to events ca. 1996. And strlcpy() and strlcat() appear not to have made it into POSIX. That paper mentions performance consequences of strncpy()'s zeroing bytes after the terminator when the target buffer may be much larger than the source. It does not mention that str(l|n)cat() suffers a similar performance impact when concatenating multiple strings into a single buffer because the content previously concatenated must be re-scanned to find the null terminator. Of course, the programmer could bypass this by using the length returned by strlcat()/strlcpy() as an offset in the target. But this reintroduces the hazard of programmer arithmetic errors. If strlcat() were inline rather than a library function, an optimizing compiler could take care of much of this by remembering the length of the previous call. You, Lynn, and John G. are correct to distrust null-terminated strings. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Strings (hijacked from: The IBM zEnterprise EC12 announcment)
In CAHm_n2m0YMNqapMVRe=sxzmayt1w9vvzvs+3v25eithm_c6...@mail.gmail.com, on 09/04/2012 at 12:10 PM, Kirk Wolf k...@dovetail.com said: But other metal-level language implementations are not care free - consider length-prefixed strings - the programmer must still check lengths before moving data. Not if STRINGRANGE is enabled. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
