Re: [HACKERS] [INTERFACES] ECPG: FETCH ALL|n FROM cursor - Memory allocation?
Michael Meskes wrote: On Thu, Apr 25, 2002 at 12:42:00PM +0100, Lee Kindness wrote: Should the input pointers be NULL initialised? How should the memory be freed? A simple free() will do. You also can free all automatically allocated memory from the most recent executed statement by calling ECPGfree_auto_mem(). But this is not documented and will never be. The correct way is to free(array1) and free(array2) while libecpg will free the internal structures when the next statement is executed. Never, never mix these two! ECPGfree_auto_mem will free even memory which has already been free'd by the user, perhaps we should get rid of this method (any allocated memory regions are stored in a list, if you never call ECPGfree_auto_mem, this list grows and grows). Christof ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [INTERFACES] ECPG: FETCH ALL|n FROM cursor - Memory allocation?
Okay, lets see if i've got this right... If I allocate the memory before the FETCH then I (naturally) free it. However If I NULL initialise the pointer then libecpg will allocate the memory and I must NOT free it - libecpg will free it automatically... Yeah? I think this highlights the need for some documentation on this aspect. Regards, Lee Kindness. Christof Petig writes: Michael Meskes wrote: On Thu, Apr 25, 2002 at 12:42:00PM +0100, Lee Kindness wrote: Should the input pointers be NULL initialised? How should the memory be freed? A simple free() will do. You also can free all automatically allocated memory from the most recent executed statement by calling ECPGfree_auto_mem(). But this is not documented and will never be. The correct way is to free(array1) and free(array2) while libecpg will free the internal structures when the next statement is executed. Never, never mix these two! ECPGfree_auto_mem will free even memory which has already been free'd by the user, perhaps we should get rid of this method (any allocated memory regions are stored in a list, if you never call ECPGfree_auto_mem, this list grows and grows). Christof ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [INTERFACES] ECPG: FETCH ALL|n FROM cursor - Memory allocation?
On Mon, May 06, 2002 at 09:37:18AM +0200, Christof Petig wrote: Never, never mix these two! ECPGfree_auto_mem will free even memory which has already been free'd by the user, perhaps we should get rid of That's why I discourage the usage of ECPGfree_auto_mem by the user. There is only one reason why the symbol is not static and that is that it is used by another module in libecpg. I never thought about this as an end user routine, it's just meant as a clean up method in case of an error during statement execution. BTW Christof, ECPGfree_auto_mem is used by testdynalloc.pgc. Maybe we should change that. this method (any allocated memory regions are stored in a list, if you never call ECPGfree_auto_mem, this list grows and grows). That is not true. Before a statement is executed libecpg calls ECPGclear_auto_mem which just frees ecpg's own structure but not the memory used for data. Michael -- Michael Meskes [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] [INTERFACES] ECPG: FETCH ALL|n FROM cursor - Memory allocation?
Lee Kindness wrote: Okay, lets see if i've got this right... If I allocate the memory before the FETCH then I (naturally) free it. However If I NULL initialise the pointer then libecpg will allocate the memory and I must NOT free it - libecpg will free it automatically... Yeah? No, I only said: Never mix free and ECPGfree_auto_mem because ECPGfree_auto_mem will double free it if you free'd it already. And also: it might be a good idea to kill the undocumented function (and the list). And: You need to free it (by one of the two methods above). I think this highlights the need for some documentation on this aspect. Yes it does. Christof ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
