ExecSG memory allocation question.

I’m recreating a old library that should be using AllocMem().

In the autodocs it says AllocVec() and AllocMem() functions are obsolete.

Is it safe to free memory allocated with AllocVec() with FreeMem() instead of FreeVec() function? On AmigaOS4.1, can I mix or match these functions, do all function point to same place? Or will this fu*k up the OS.

I probably miss something but for what reason would you want to FreeMem() memory allocated with AllocVec()?
Internally AllocMem() probably defaults to AllocVec() but it may also perform different things prior this.
So my advise would be always match allocation methods with appropriate freeing one, and you would always be on the safe side.

If your target API supports AllocVec() it should support also FreeVec(), so the question is.. why?
Anyway create your test case and try it!

@abalaban

I expect programs that use powerpacker.library to use FreeMem() function to free the memory, thats allocated by this powerpacker.library, this is something I can't change..

So can I use something else then AllocMem()? or am I forever stuck with legacy AllocMem().

@LiveForIt
I don't know exactly, but API wise AllocMem() pairs with FreeMem() and AllocVec() pairs with FreeVec(). Regardless what you might find by trying it out, I wouldn't consider criss-crossing the pairs a safe path unless it becomes publicly documented in the AutoDocs that its allowed to do so.
Even if it works (which I wouldn't expect it to) the implementation could change and break you library.

So, yeah, I'd say you're stuck with good old deprecated AllocMem().

Quote:


This is the real issue here.

This powerpacker.library API is broken by design if it really relies on the caller to free memory with a certain system function, which was allocated by the library's code and not actually by the caller himself. So the only real fix to this issue would be to deprecate the function in powerpacker.library containing the implicit memory allocation and create a new pair of libraries to create and free the corresponding data structures. Old software would continue to work using the old function and their own FreeMem(), new software would use the new function pair leaving the details of memory allocation fully up to the library's implementation.

Quote:

No, you MUST NEVER intermix different function pairs, just because they seem to do similar things. AllocMem/FreeMem is NOT interchangeable with AllocVec/FreeVec as they simply are different function pairs. Whatever they might do internally must not be of your concern as it is continuously subject to change without warning and would rather sooner than later break your software, if it wouldn't break it right from the start.

@Cyborg

The API allows the users to define memory type of the destination buffer (uncompressed data), and the program is supposed free memory itself, when the program is done with memory.

I guess I can do it internally, I know what API is calling the function, so I can put “if” in there to handle it, but this can cause confusion, and it be easy to forget, to change memory free function.

I think your correct, it be better to deprecate the function, to properly inform the developers that they should not use it. this will cause developers to look up the autodocs.

I think maybe a callback hook, can be good idea, for memory allocation function, so developer have full control over it. some developers don’t like callback hooks, but it already use it for progress updates, and custum password input dialogs.

I can only repeat that the way to go would be to provide proper alloc/free function pairs in your (it is yours?) library code (maybe even multiple pairs, if needed. Or with flags for different situations, etc.) and keep the implementation details private to the library

- OR -

leave full control to the caller. So the caller would then be responsible for allocating appropriate memory and freeing it again.


I'd personally always go for the first/internal approach if anyway possible. This way you have full control over the memory you are going to use elsewhere in your code and don't have to rely on the assumption/hope developers will do the right thing.

Only if there really is no choice, I'd leave the memory handling up to the caller, but then also in full, without interfering with it in the straight assumption I will get the correct memory denying any responsibility.

This really is a black/white thing without any greys IMHO.