|
> The way you describe ALLOC and DEALLOC is pretty much an industry standard > from what I've seen and so wouldn't, IMO, be considered "quirky" in RPG > unless you consider them quirky in all languages. C is an industry standard... but I still think it's quirky. :) > True. No alloc I've seen does this, although I'm kinda hazy on Basic's > implementations. Easy enough to write a wrapper around RPGs ALLOC for this > though to initialize the data without having to code an MI ALLOC. That's essentially what I'm doing, but I'm not using MI for the allocation. I'm using the CEEGTST API, and memset() for the initialization. I was only interested in MI because I could find no other way to determine the allocation size for a given pointer. > DEALLOC has an (N) extender? Nice. C/C++ doesn't have anything like that > far as I know. I have to set it to NULL myself. It'd be nicer if it defaulted to (N). > About the only real error I know of with ALLOC is not enough memory to alloc > what I want. Nothing else even comes to mind. CEE0802 - Storage headers are damaged. CEE0803 - Heap identifier does not match existing heap. CEE0808 - Requested storage size is not valid. CEE0813 - Insufficient storage available to satisfy request. > With DEALLOC the only error I know of is that the pointer given is not a > pointer to ALLOCed memory. CEE0802 - Storage headers are damaged. CEE0810 - Starting address for reallocation is not valid. In any event, as I've mentioned, the compelling reason for the service program is to extend the functionality available, not to replace RPG's xxALLOC commands. That is precisely why I wish to avoid a hidden header; because I fully expect that the programmer may wish to continue using the opcodes for basic operations, and use the service program solely for the extended functions. It just so happens that building a better version of the xxALLOC codes is easy to do, so I didn't mind spending an extra hour to add them into the library. Regards, John Taylor
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.