aglew@ccvaxa.UUCP (07/18/87)
/* Written 9:03 am Jul 17, 1987 by rcb@rti.UUCP in ccvaxa:comp.os.vms */ In article <2961@blia.BLI.COM> forrest@blia.BLI.COM (Jon Forrest) writes: >For example, let's say that a sharable image contains variable A which >is 10 bytes long and begins at location 100 and variable B which is >20 bytes long and begins at location 110. We can assume both are >universal symbols. The user links an application program that references >both variables with this sharable image. Everything works fine. >Meanwhile, the software developer who sold the user the shareable >image modifies variable A so that it now is 20 bytes long. This >means that variable A begins at 100, as before, but now variable >B now begins at location 120. Then, the user receives this new >shareable image and, much to his consternation, finds that his >program bombs every time he references location B. The solution is really simple. Have a section of code that will always be at a fixed address and will contain pointers to the data structures. The pointers will always be 4 bytes and the addresses won't change. You can change the size of the structure and you could even change it at run time and the program won't care since it always accesses it through the pointer that is in a known location. -- Randy Buckland Research Triangle Institute rcb@rti.rti.org [128.109.139.2] {decvax,ihnp4,seismo}!mcnc!rti-sel!rcb /* End of text from ccvaxa:comp.os.vms */
aglew@ccvaxa.UUCP (07/18/87)
/* Written 1:58 pm Jul 18, 1987 by aglew@ccvaxa.UUCP in ccvaxa:comp.os.vms */ /* Written 9:03 am Jul 17, 1987 by rcb@rti.UUCP in ccvaxa:comp.os.vms */ In article <2961@blia.BLI.COM> forrest@blia.BLI.COM (Jon Forrest) writes: >For example, let's say that a sharable image contains variable A which >is 10 bytes long and begins at location 100 and variable B which is >20 bytes long and begins at location 110. We can assume both are >universal symbols. The user links an application program that references >both variables with this sharable image. Everything works fine. >Meanwhile, the software developer who sold the user the shareable >image modifies variable A so that it now is 20 bytes long. This >means that variable A begins at 100, as before, but now variable >B now begins at location 120. Then, the user receives this new >shareable image and, much to his consternation, finds that his >program bombs every time he references location B. The solution is really simple. Have a section of code that will always be at a fixed address and will contain pointers to the data structures. The pointers will always be 4 bytes and the addresses won't change. You can change the size of the structure and you could even change it at run time and the program won't care since it always accesses it through the pointer that is in a known location. -- Randy Buckland Research Triangle Institute rcb@rti.rti.org [128.109.139.2] {decvax,ihnp4,seismo}!mcnc!rti-sel!rcb /* End of text from ccvaxa:comp.os.vms */ /* End of text from ccvaxa:comp.os.vms */
forrest@blia.BLI.COM (Jon Forrest) (07/20/87)
In article <46200001@ccvaxa>, aglew@ccvaxa.UUCP writes: > > > The solution is really simple. Have a section of code that will > always be at a fixed address and will contain pointers to the data structures. > The pointers will always be 4 bytes and the addresses won't change. You > can change the size of the structure and you could even change it > at run time and the program won't care since it always accesses it through > the pointer that is in a known location. As I said in my original posting this kind of solution wasn't what I had in mind mainly because the code has to be portable. To implement this solution I'll have to convince a bunch of people to change some non-trivial code. It is a good idea, though, since it's just the same thing as transfer vectors. Any other comments or suggestions? Jon Forrest forrest@blia.BLI.COM ucbvax!mtxinu!blia!forrest {pyramid|voder}!blia!forrest