Re: [lwip-devel] LWIP_ERROR included in release builds

[Kieran Mansley]

On Mon, 2009-03-23 at 17:03 -0400, Bill Auerbach wrote:
> Hello,
> 
> I just happened to view the binary output of my lwIP based firmware
> and noticed something that surprised me a lot.
> 
> I see several assertions in the text part of the binary.  I check into
> the text and find out that LWIP_ERROR is including assertions in
> release mode!  I.e., LWIP_DEBUG is not defined and LWIP_NOASSERT is
> defined.  I find in debug.h there is no exclusion of LWIP_ERROR if
> LWIP_NOASSERT is defined.  I think this is a bug not to do so.  To me,
> release means release.  If I didn’t catch this LWIP_ERROR check in
> debug mode testing, it’s my problem – if any of these checks fails,
> they will lock up my firmware!  (Maybe if it continues it will also, I
> can’t say.)  A workaround could be an explicit define
> (LWIP_CHECK_ERROR) if it’s desired to have it when LWIP_NOASSERT is
> defined as I feel strongly that LWIP_ERROR should not be included by
> default.
> 
> Is there a good reason to dispel my opinion?

LWIP_ERROR is deliberately permanent, and for that reason should on the
whole only be used for things that would be fatal anyway.  For example,
if without the LWIP_ERROR we would dereference a NULL pointer, your
firmware will likely die whether the LWIP_ERROR is compiled in or not.
With it compiled in, you at least get some useful output about what went
wrong.  Also, LWIP_ERROR takes a third argument - the handler - which is
intended to be the action if you choose not to make it fatal.  If you
define LWIP_ERROR to take this path, it should do the right thing, eg.
return an error code instead of continuing with the function.
LWIP_ERROR and the other similar macros are all defined in such a way
that your port can override them with an alternative behaviour if that
is what you require.

Hope that helps,

Kieran