Re: [lwip-devel] Extended udp_recv callback

[Jonathan Larmour]

Kieran Mansley wrote:
> 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);

For clarity I didn't throw in the various casts that would otherwise be
required :-). pcb->recv would be a function pointer which could have two
different function signatures. In the PCB itself you might want it to be
declared as a generic function pointer i.e. having type "void (*)(void)".

Of course in my hypothecated scenario, the parameters to udp_recv() or
udp_set_recv_callback() _would_ have to have the correct types for the
function pointer, so from the user's point of view, there is still the
appropriate type checking.

Jifl
-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine