I understand the concerns, but this sounds like a good reason for all ISVs to review their code. Consider the case of user key common storage: that took a while to get code clean, but it was a good thing, and worth the effort. My point is that there is no 100 byte limit on the interface, there is only a limit on the implementation. >>> P S <[email protected]> 9/24/2009 10:01 AM >>> On Thu, Sep 24, 2009 at 9:31 AM, Scott Rowe <[email protected]> wrote: > [rant] > This whole thread really irks me. Simply the idea that a program might move > a variable length string without first checking for limits is just appalling. > I would be pretty ashamed if I found I had done that in any of my personal > programs, let alone any code I wrote when I was working for an ISV, > authorized or not. This is the very type of sloppy code that causes many of > Microsoft's security exposures. I thought that we, as a community, had > better discipline than that. > > I know I would never assume that the parm string passed to one of my programs > was no longer than 100 bytes, even if there is a JCL limitation, simply > because I wouldn't assume that I was always being called from JCL. Even if I > checked to be sure I was being called from JCL I wouldn't skip the check, I > would still write the one or two more instructions to do the check because I > can't be sure that nothing will ever change. > [/rant] > We now return you to your previously scheduled programming.
I would hope that I would never do that, either. However, for code that uses an interface that has been unchanged for 45 years with a 100-byte limit, I'm not sure I'd be quite that hard on someone whose code copied the data into a 100-byte buffer using the supplied length. To turn it on its head: I wouldn't play you-bet-your-system with this. The code in most vendor products isn't as well vetted as your own internal code, and is a lot harder to examine. Guns have safeties for a reason; so should a change like this. Whether it's a new interface (PARMX) or an LE setting that must be explicitly enabled, there needs to be some informed consent. I can't imagine IBM being willing to even consider it otherwise -- else a (poorly written) program that's been happily running for decades could crater production, and nobody wants that. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
