On Wed, Sep 23, 2009 at 10:59 AM, Thompson, Steve < [email protected]> wrote:
> > Might I suggest that you are being a bit myopic? Or perhaps suffering > from tunnel vision? > > APF programs are to be written to a higher standard. > > From what you have written, you believe that if someone passes an APF > program you have written, an invalid parm, that program should accept > that as gospel and go clobber some part of the address space (say the > JSCB, or change the ASCBSENV, etc.) and give the caller authorities they > should not have, right? > > I think you're missing the point entirely Steve. This has nothing to do with APF or non-APF and nothing at all to do with abstract program A calling theoretical program B. The consequences for an APF program are potentially more serious, but the problem is the same. Back before the flood the PARM interface was explicitly limited to 100 bytes. So a valid program written to that specification could legally pick up the length and mindlessly move that many bytes from the parameter data into another pre-allocated (or dynamically allocated) 100 byte area knowing full well there was no chance of overflow because the OS guaranteed (then) that the actual length would never be greater than 100. Fast forward 4 decades and change the interface so the length could go over 100 and now you have valid programs that can suddenly overlay their 100 byte area. Nothing good can come of it and if you're lucky you just abend right then and there. If you're an APF program then things can go awfully pear shaped. An interface definition is a contract. You can't break it, even if the original contract (as in this case) was stupid. -- This email might be from the artist formerly known as CC (or not) You be the judge. ---------------------------------------------------------------------- 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
