[lwip-devel] [task #6969] Review usage of conn->err in netconn layer

[Jonathan Larmour]

Follow-up Comment #21, task #6969 (project lwip):

I saw some discussion on IRC about this task. Two things occur to me:

1) in my drivers, I had already been using ERR_IF to indicate a fatal error
in driver operation. For example, trying to send on an interface that was
never successfully brought up; or sending a pbuf chain with more elements in
the chain than the driver supports (for drivers that support scatter-gather
DMA).

So it's true that drivers sometimes need to provide fatal errors. But it's
also true that drivers may have transient errors, and there is no good code
for that. Which brings me to....


2) There seemed to be a bit of to-ing and fro-ing about which errors should
be fatal or not. The problem seems to be that in some contexts a failure can
be fatal, and sometimes not, even if the reason is the same (e.g. out of
memory).

May I suggest instead making the internal representation of the error in
conn->err be interpreted as a bitmask. The values are already negative, so
instead of the top bit, maybe bit 6 could indicate if a failure is minor or
fatal.

Then ERR_IS_FATAL() just needs to test that bit. ORing (or not ORing) that
bit will not be any more code because the compiler will make it a constant
either way.

Just a thought.


    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/task/?6969>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/