[Swan-dev] typing libevent callback functions

Antony Antony antony at phenome.org
Thu Jan 29 02:45:05 EET 2015


On Sun, Jan 25, 2015 at 04:10:12PM -0500, D. Hugh Redelmeier wrote:
> Getting callback functions right is tricky.  One tool that can detect
> some problems is the C type system.

I see some appeal this idea, however, I don't have a clear picture of what could potentially go wrong otherwise. What kind of error would be caught in the context we are using. I think this could be useful if function pointer is stored in a variable, such as crypto_req_cont_func is used. So far that is not the case for the libevent callbacks. We just pass the function pointer to libevent using pluto_event_new. Any references for further reading?

Having said that, this is a minor change lets do it. One clarification question bellow.

> This approach was used with crypto request continuations.  See how the
> type crypto_req_cont_func is used.
> 
> I think that this technique/convention should be used for libevent
> callbacks.
> 
> It requires a typedef for callback functions.
> 
> Unfortunately, libevent2's event.h declares a type that is called
> event_callback_fn but is really a POINTER to a function:
>   typedef void (*event_callback_fn)(evutil_socket_t, short, void *);
> 
> We have to provide our own typedef:
>   typedef void event_callback_routine(evutil_socket_t fd, short events, void *arg);
> Notice that I've included the normal argument names: I think that it
> makes their meaning clearer.
> 
> We should declare each callback function with this type.  That's how
> to get the compiler to enforce the type matching requirements.  It
> also is a flag to the reader that the function is a callback function.
> 
> extern event_callback_routine do_read_cb;
> 
> Unfortunately you cannot define the functions using this type because
> a function definition needs an explicit parameter list.
> 
> void do_read(evutil_socket_t fd, short events, void *arg) {
> 	/* whatever */
> }
> 
> I suggest that each callback function use the same names for formal
> parameters.  (This is not currently the case.)

good catch. That is great idea.

> 
> Here's a list of the callback functions used with pluto_event_new:
>     kernel_process_msg_cb
>     kernel_process_queue_cb
>     comm_handle_cb
>     handle_helper_answer_cb
>     timer_event_cb

do we need one typedef per function? I am guessing not.
Please take a look at bdf978aa5b441fec27. Is the right direction?

thanks,
-antony


More information about the Swan-dev mailing list