|
Scott, >This implies that when the module is loaded into memory that it's not >initializing its variables to NULL, as I believe that it should. These were *Entry parameters, so it can't initialize the variables. When you use a *Entry PLIST, it expects to find pointers for each PARM on the call stack. Since a previous invocation of TEST1 had put pointers there and the call to TEST2 had not replaced any of them, the pointers were still sitting on the stack. >It seems to me that the addresses of the parameters should be *NULL if >they weren't ever SET by passing parms to the procedure. XTEST did not use a prototyped call to TESTn, so it has no way of knowing that TEST2 may be expecting 5 parameters. All RPGLE programs will show a parameter range of 0 minimum to 255 maximum in the object description. (Do a DSPPGM and roll down 3 times to see this.) So do you think it should have called TEST1 with 5 pointers followed by 250 null pointers, and TEST2 with 255 null pointers? At 16 bytes per pointer, that would seem to be a waste of about 4K per call level just to hold null pointers. How significant is that in today's architecture? I don't know. >The fact that >they happened to point to the same area of memory that the previous >procedure pointed to seems like an extraordinary coincidence! Not to me. That's just the way that stacks work. I'd be more surprised if it *didn't* behave the way Mark experienced. This just exemplifies the advantages of using prototyped calls (when possible) and using %parms to check how many parameters were actually passed. Doug +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.