[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: Frédéric Bernon
Subject: [lwip-devel] [task #6969] Review usage of conn->err in netconn layer
Date: Mon, 26 Nov 2007 20:35:36 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv: Gecko/20071025 Firefox/

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

>What I might like is something like a non-fatal ERR_IF. 

Adding some new error codes doesn't really have a high cost. But in your case
("my driver is if someone tries to send a packet where the pbuf chain is more
than the driver can cope with"), what should be the application processing ?

>Maybe we should define what the difference between ERR_MEM and ERR_BUF is. I
think returning ERR_BUF here might work

I think we should return ERR_MEM on mem_alloc error, and on sys_xxx_new
errors (even if in some cases, it could be better to return a "fatal" error
code). ERR_BUF is more for memp and pbuf allocation errors.

>And another problem would be that all old errors would be non-fatal (since
bit6 = 0), so that would have to be turned around so that only new code can
generate non-fatal errors.

I think the initial idea which a "less than" compare "is simpler" to
understand and maintain. More, if a non-fatal code is -5 and a fatal is -69
(-5 | bit6=1), how do you process the err_to_errno_table ?


Reply to this item at:


  Message posté via/par Savannah

reply via email to

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