Of course, let's not overlook the distinction between an invalidly constructed parameter list and parameters with invalid data. The construction can be valid (fullword alignment, last pointer high-bit on) but parameters can still hold or point to bad data.
Validating data is always important; otherwise, yes, "weird" things have been known to happen. Many, many years ago, I debugged a problem caused by someone's "slick" method of iterating through a list of programs in order to call them sequentially via BLDL/LOAD. The list held reserved, blank entries so program names could be zapped in later. Works fine unless a load module with a name of spaces exists on the system (don't ask me how). Called but totally unrelated to anything at all, the program opened files, read, and maybe wrote, records, and finally went boom! So, now, "a-billion-in-one" is now "a-thousand-in-one," maybe? (Plus, given only a dump, finding the root cause of something like this is incredibly difficult, if not impossible.) That could all have been avoided with a simple "is the data not spaces?" validation. Doug Watkins The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of McKown, John Sent: Wednesday, August 11, 2010 3:13 PM To: [email protected] Subject: Re: Parameter passing: overly cautious or properly paranoid? > -----Original Message----- > From: IBM Mainframe Assembler List > [mailto:[email protected]] On Behalf Of Binyamin Dissen > Sent: Wednesday, August 11, 2010 1:51 PM > To: [email protected] > Subject: Re: Parameter passing: overly cautious or properly paranoid? > <snip> > :>of confidence that might well lead you to having an > integrity exposure. > > Obviously if the called routine has greater authority than the caller, > everything must be checked in detail. > > But if it runs at equal authority there is nothing the caller > can do, no > matter how much the plist is messed up, to affect integrity. > > -- > Binyamin Dissen <[email protected]> > http://www.dissensoftware.com > > Director, Dissen Software, Bar & Grill - Israel FSVO "integrity exposure". If I don't validate the parameters, then I may "do something" with invalid data which does not cause an exception. I then return "something" to the caller. Who may then "do something" with that data, such as write it to a file. You now have a "data integrity" problem. That is, the data in the file has been silently compromised. And you have no idea where the corrupt data came from. I have this problem with an in-house routine which, on rare occassion, is passed invalid data. The routine can then corrupt other memory locations. Which happened this last Monday in such a way as to abend CICS. This may not be an "integrity exposure". But suppose instead of abending CICS, it simply corrupted another task's memory in such a way that the task malfunctioned by granting a user access to something they shouldn't have access to. Granted, a billion in one shot. But not totally impossible. Paranoiad programmer. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-691-6183 cell [email protected] * 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
