yes any functions that take pointers to pointers and leave you with null will indicate you don't have to do anything.
On Tue, Jun 29, 2010 at 2:23 PM, Mathieu Rene <[email protected]> wrote: > Also note that switch_event_fire() will internally free the event once the > handlers have processed it. > > Mathieu Rene > Avant-Garde Solutions Inc > Office: + 1 (514) 664-1044 x100 > Cell: +1 (514) 664-1044 x200 > [email protected] > > > > > On 2010-06-29, at 3:00 PM, Anthony Minessale wrote: > > This is mostly true > minor corrections below: > > most functions who return an opaque pointer with no sign of a session or > pool are expected to be destroyed. > The rule of thumb is if they take an double pointer or return a pointer to > something opaque or a string it's a safe assumption it needs to be destroyed > either by looking for a corresponding destroy function or regular > switch_safe_free on strings. > > > On Tue, Jun 29, 2010 at 8:36 AM, Steven Ayre <[email protected]> wrote: > >> memory free is sometimes used, but often not needed because of memory >> pools. >> >> Sessions and channels have their own memory pool, anything creating memory >> for one of them will not need freeing as when the session ends the entire >> pool is destroyed. Similarly many modules have a pool which lasts for the >> lifetime of the module. >> >> There are other functions which will need freeing though... I suggest that >> you use switch_safe_free() to be consistent with the rest of freeswitch. >> It's just a wrapper on free which doesn't call it for a null pointer >> (avoiding a segfault on some systems). >> >> Some examples: >> - switch_snprintf & switch_mprintf needs a free (is given no pool or >> object with a pool) >> > *switch_snprintf does not need free it takes a buffer and memory size > as args like real snprintf* > > >> - switch_core_session_sprintf does not need a free (it's given a session, >> memory is allocated from its pool) >> - switch_channel_expand_variables sometimes needs free, sometimes doesn't >> (you give it a buffer, if it's large enough its used and returned otherwise >> it creates a new one, so you should check the return value against the >> buffer to avoid either freeing a const char or a buffer twice). >> >> *switch_channel_expand_variables only uses dynamic memory if something > was expanded in the string. If it does not expand anything it returns the > original input pointer so you can tell if you need to free it if the output > != input string.* > > > > > >> -Steve >> >> >> On 29 June 2010 06:19, Paul Li <[email protected]> wrote: >> >>> A lot of FreeSwitch core APIs, such as switch_event_dup(switch_event_t >>> **event, switch_event_t *todup), returns a pointer to an allocated >>> memory chunk, should the caller always releases that memory chunk by >>> calling a proper API, such as switch_event_destroy(switch_event_t >>> **event)? >>> >>> I could not find any documentation to detail the general rule >>> regarding memory allocation/free when using the core APIs. >>> >>> Thank you for your attention! >>> >>> _______________________________________________ >>> FreeSWITCH-dev mailing list >>> [email protected] >>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev >>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev >>> http://www.freeswitch.org >>> >> >> >> _______________________________________________ >> FreeSWITCH-dev mailing list >> [email protected] >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev >> http://www.freeswitch.org >> >> > > > -- > Anthony Minessale II > > FreeSWITCH http://www.freeswitch.org/ > ClueCon http://www.cluecon.com/ > Twitter: http://twitter.com/FreeSWITCH_wire > > AIM: anthm > MSN:[email protected] <msn%[email protected]> > GTALK/JABBER/PAYPAL:[email protected]<paypal%[email protected]> > IRC: irc.freenode.net #freeswitch > > FreeSWITCH Developer Conference > sip:[email protected] <sip%[email protected]> > googletalk:[email protected]<googletalk%3aconf%[email protected]> > pstn:+19193869900 > _______________________________________________ > FreeSWITCH-dev mailing list > [email protected] > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org > > > > _______________________________________________ > FreeSWITCH-dev mailing list > [email protected] > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org > > -- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:[email protected] <msn%[email protected]> GTALK/JABBER/PAYPAL:[email protected]<paypal%[email protected]> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:[email protected] <sip%[email protected]> googletalk:[email protected]<googletalk%3aconf%[email protected]> pstn:+19193869900
_______________________________________________ FreeSWITCH-dev mailing list [email protected] http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
