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 <mrene_li...@avgs.ca> 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 > mr...@avgs.ca > > > > > 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 <stevea...@gmail.com> 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 <plite2...@gmail.com> 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 >>> FreeSWITCH-dev@lists.freeswitch.org >>> 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 >> FreeSWITCH-dev@lists.freeswitch.org >> 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:anthony_miness...@hotmail.com <msn%3aanthony_miness...@hotmail.com> > GTALK/JABBER/PAYPAL:anthony.miness...@gmail.com<paypal%3aanthony.miness...@gmail.com> > IRC: irc.freenode.net #freeswitch > > FreeSWITCH Developer Conference > sip:8...@conference.freeswitch.org <sip%3a...@conference.freeswitch.org> > googletalk:conf+...@conference.freeswitch.org<googletalk%3aconf%2b...@conference.freeswitch.org> > pstn:+19193869900 > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev@lists.freeswitch.org > 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 > FreeSWITCH-dev@lists.freeswitch.org > 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:anthony_miness...@hotmail.com <msn%3aanthony_miness...@hotmail.com> GTALK/JABBER/PAYPAL:anthony.miness...@gmail.com<paypal%3aanthony.miness...@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:8...@conference.freeswitch.org <sip%3a...@conference.freeswitch.org> googletalk:conf+...@conference.freeswitch.org<googletalk%3aconf%2b...@conference.freeswitch.org> pstn:+19193869900
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
