Re: [lwip-devel] [bug #27034] Invalid ASSERT in pbuf_alloc()

[address@hidden]

Bill Auerbach wrote:
> > However, I'd like to know what the purpose of
> >
> >  pbuf_alloc(PBUF_RAW, 0, PBUF_POOL);
> >
> > is? Since there is no API that supports increasing a pbuf's length
> > without
> > moving the payload to the front (which you can't in this case, because
> > PBUF_RAW is used), you'll end up with a pbuf of zero length, which is
> > bound to
> > lead to problems in other parts of the stack. There are checks for pbuf-
> >     
> > > len
> > >       
> > not being zero somewhere... (although I don't remember where and why).
> >     
>
> The above is used in PPP,

To me, that's not a reason to allow zero-length pbufs: the PPP code is 
unfortunately not very actively maintained and thus may (beside this 
one) contain other bugs or invalid code: lines like

     *((u_char*)nb->payload + nb->len++) = PPP_ESCAPE;

in ppp.c are, strictly seen, bugs, as the pbuf->len value may not be 
changed by code external to pbuf.c. I'd rather fix that than allowing 
zero-length pbufs throughout the stack (which is in most cases a bug).

>  and I use:
>
> pbuf_alloc( PBUF_RAW, 0, PBUF_REF )
>
> in my application.  It's useful for zero-copy output operations.
>   

So you're fiddling around with pbuf->len, too? Code like that is not 
supported! In general, application code playing around with lwIP struct 
members without using API functions provided for that use is (except for 
some rare cases) not allowed/supported. Unfortunately, with C, it can't 
really be avoided by our code/files in a decent way. [There are some 
rare cases like netif->flags= where most available code uses the 
internal struct members, but I'd vote for introducing API 
functions/defines for these places, too.]

You should know the length before calling pbuf_alloc() and pass it 
instead of 0.

Simon