Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
54 user(s) are online (42 user(s) are browsing Forums)

Members: 0
Guests: 54

more...

Headlines

 
  Register To Post  

ExecSG memory allocation question.
Home away from home
Home away from home


See User information
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.

(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.
Go to top
Re: ExecSG memory allocation question.
Quite a regular
Quite a regular


See User information
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.

Back to a quiet home... At last
Go to top
Re: ExecSG memory allocation question.
Just popping in
Just popping in


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

Memento audere semper!
Go to top
Re: ExecSG memory allocation question.
Home away from home
Home away from home


See User information
@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().

(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.
Go to top
Re: ExecSG memory allocation question.
Just popping in
Just popping in


See User information
@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().

- Thomas
Go to top
Re: ExecSG memory allocation question.
Just popping in
Just popping in


See User information
Quote:
LiveForIt wrote:

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..



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:
So can I use something else then AllocMem()? or am I forever stuck with legacy AllocMem()


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.

AmigaOS 4 core developer
www.os4welt.de - Die deutsche AmigaOS 4 Gemeinschaft

"In the beginning was CAOS.."
-- Andy Finkel, 1988 (ViewPort article, Oct. 1993)
Go to top
Re: ExecSG memory allocation question.
Home away from home
Home away from home


See User information
@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.


Edited by LiveForIt on 2022/7/13 13:42:46
(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.
Go to top
Re: ExecSG memory allocation question.
Just popping in
Just popping in


See User information
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.

AmigaOS 4 core developer
www.os4welt.de - Die deutsche AmigaOS 4 Gemeinschaft

"In the beginning was CAOS.."
-- Andy Finkel, 1988 (ViewPort article, Oct. 1993)
Go to top

  Register To Post

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project