Ibukun Olumuyiwa <[EMAIL PROTECTED]> [2004-05-08 12:01]: > On Sun 02 May 2004, Gen Zhang wrote: > > > > I quote from source: > > /** > > * Add an event to the event queue. > > * @param type The event type to add to the end of the event queue > > * @param ev The private data structure for this event type > > * @param func_free The function to be called to free this private structure > > * @param data The data pointer to be passed to the free function > > * @return A Handle for that event > > * > > * On success this function returns a handle to an event on the event queue, > > or > > * NULL if it fails. If it succeeds, an event of type @p type will be added > > * to the queue for processing by event handlers added by > > * ecore_event_handler_add(). The @p ev parameter will be a pointer to the > > event > > * private data that is specific to that event type. When the event is no > > * longer needed, @p func_free will be called and passed the private sructure > > * pointer for cleaning up. If @p func_free is NULL, nothnig will be called. > > * This function is passed @p data as its data parameter. > > */ > > I am confused as to what happens if func_free is NULL. "nothing will be > > called". Is that supposed to be a failure condition (as the following code > > seems to indicate) or is the doc wrong? > > If func_free is NULL, then ecore's generic event free function is used. > This is OK as long as your event struct does not contain any dynamically > allocated data such as strings etc., which would cause memory leaks. So > the rule is if you have a pointer to malloc'ed data like a string or a > struct, you write your own free function that will make sure those > pointers are freed before freeing the event itself.
That's not true. Ecore_Event * ecore_event_add(int type, void *ev, void (*func_free) (void *data, void *ev), void *data) { if (!func_free) return NULL; /* snip */ } IMHO, the code should be changed so it behaves the way you described. Any objections? -- Regards, Tilman ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 _______________________________________________ enlightenment-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel