Re: [lwip-devel] Extended udp_recv callback

[Kieran Mansley]

On Tue, 2009-01-13 at 16:39 +0000, Jonathan Larmour wrote:
> Kieran Mansley wrote:
> > 
> > I think a combination of the two approaches might be best:
> >  - add an extra callback to the API, something like pcb->recv_ext() with
> > an associated means of setting a handler for this callback. 
> >  - have a pcb->flag that selects whether to use the normal recv callback
> > or the extended recv callback.
> >  - have a compile time EXTENDED_RECV_CALLBACK definition that can be
> > used to compile the extended recv callback feature out if others don't
> > want it.
> > 
> > That way existing code doesn't need to be modified as the old callback
> > remains the same.
> 
> Just to be clear, my suggestion meant that existing code doesn't have to
> change either.

I didn't see how you'd avoid changing the type of the recv callback
function.  In the bit I snipped you have it calling pcb->recv() with
different numbers of arguments:

if (pcb->flags & UDP_FLAGS_RECV_LEGACY)
  pcb->recv(pcb->recv_arg, pcb, p, &(iphdr->src), src);
else
  pcb->recv(pcb->recv_arg, pcb, p, dstaddr, dstport, &(iphdr->src),
src);

> But doesn't have the pcb overhead of an extra function
> pointer+argument in the UDP PCB.

That is definitely an advantage.  I think users who want the extra
functionality would be willing to take the hit though, and everyone else
will be compiling it out with the compile-time switch (should definitely
default that way).

Kieran