RE: [lwip-devel] Extended udp_recv callback

[bill]

> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden On
> Behalf Of Jakob Stoklund Olesen
> Sent: Tuesday, January 13, 2009 12:16 PM
> To: lwip-devel
> Subject: Re: [lwip-devel] Extended udp_recv callback
> 
> 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.
> 
> I like this. Let me write a patch and get back to you.
> 
> I will do something like this:
> 
> #if UDP_EXTENDED_CALLBACK
>   if (pcb->flags & UDP_FLAGS_EXTENDED_CALLBACK) {
>     ((udp_extended_callback_function)pcb->recv)(pcb->recv_arg,
>       pcb, p, &(iphdr->src), src, &(iphdr->dest), inp);
>   } else
> #endif /* UDP_EXTENDED_CALLBACK */
>   {
>     pcb->recv(pcb->recv_arg, pcb, p, &(iphdr->src), src);
>   }
> 
> Pointer-to-function casting is safe isn't it?

Yes.  Maybe make a typedef for the callback and change that typedef if
UDP_EXTENDED_CALLBACK is defined.  Since the new default typedef matches the
current callback function pointer type, the types are still considered the
same and it won't affect existing code that doesn't use the new typedef.

I've wondered on an off why all of the lwIP struct types aren't typedefed to
just the tag name to make the code a bit easier to read and require less
typing.  E.e. typedef struct { current pbuf members } pbuf;

Bill