[lwip-devel] [patch #5926] Use function pointers instead of table index in api_lib/api_msg

[Frédéric Bernon]

Follow-up Comment #5, patch #5926 (project lwip):

>why do you mark the do_*() functions as extern? We don't have that anywhere
in the stack (except for lwip_strerr() and some ppp functions). Wouldn't
extern mean the functions are in another library? 

It's just a thing I always do, most of time because I often mix C++ code with
C code, and "extern" works for both. But yes, it's not necessary (I will
remove them)

>I would favour defining api_msg_post() to tcpip_apimsg() instead of
tcpip_apimsg(). That way we're still open to let it do something else and
code size stays the same. 

I don't like this idea, just because it's add a "function call" for nothing.
One of my first idea was to use a "define" like "#define api_msg_post
tcpip_apimsg", but finally, I think it's "gadget" and I prefer to show what
is really call. More, because the api_msg_input is also remove, it's more
"symetric" in this case. Last, If we want to decide to change the
communication between api_lib and api_msg, I think it's better to directly do
it in tcpip_apimsg (by example, to replace the
"sys_mbox_fetch(apimsg->msg.conn->mbox, NULL);" by something else to do
asynchrone calls). But If others really prefer the "define" solution, we
can...

>What is it with this variable 'msg_copy'? Why was it used and why is it
obsolete, now? 

When we have replace in tcpip_apimsg the memp_alloc by a local variable
"struct tcpip_msg msg;", someone suggest to add it (I don't remember, but the
idea was perhaps due to err_tcp problem). I don't think it's necessary,
because the "sys_mbox_post(msg->conn->mbox, NULL);" in api_msg is always the
last instruction in a "do_xxx" function. Exception is do_connect (which wait
a err_tcp or a do_connected calls). But if you see something I miss, tell
me...






    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/patch/?5926>

_______________________________________________
  Message posté via/par Savannah
  http://savannah.nongnu.org/