[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jonathan Larmour
Subject: [lwip-devel] [task #6969] Review usage of conn->err in netconn layer
Date: Mon, 26 Nov 2007 16:20:05 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060513 Fedora/1.0.8-1.1.fc3.1.legacy Firefox/1.0.8

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

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

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

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:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]