lwip-devel
[Top][All Lists]
Advanced

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

[lwip-devel] RE: [lwip-users] PBUFS + LWIP 1.3.0 + memory allocation


From: Bill Auerbach
Subject: [lwip-devel] RE: [lwip-users] PBUFS + LWIP 1.3.0 + memory allocation
Date: Wed, 10 Feb 2010 13:24:27 -0500

Thank you - good explanation.  Not all compilers support the keyword inline
and if they do parse it are allowed to ignore it.

Worse is that every inclusion of pbuf.h that didn't define mem_realloc will
cause this function to be defined.  Since it returns an argument, there will
be compilers that generate code and create multiple copies of this function.
It's small but still wasteful.  I believe function definitions are not
appropriate in H files because you don't know how they will be handled.
 
Bill

>-----Original Message-----
>There is a version of mem_realloc in mem.h that is marked 'static' but
>not 'static inline'.  This version is activated only with certain
>lwipopts settings.  Any source file that includes mem.h gets a new
>version of the code compiled within it.  If the source file doesn't
>reference mem_realloc, that code is unreachable (hence the warning).
>So you'd expect to get this warning in any file that included mem.h
>*except* for pbuf.c (since pbuf_realloc actually references the
>function).
>
>For a gcc user, it would be better if it were declared 'static inline'
>because then gcc doesn't complain (and doesn't generate any code
>unless it's referenced).  I don't know how that translates to other
>compilers.
>
>Jeff
>






reply via email to

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