buglwIP - A Lightweight TCP/IP stack - Bugs: bug #2942, pbuf_realloc cannot not grow...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #2942: pbuf_realloc cannot not grow chains (can only shrink chains).

Submitter:  Leon Woestenberg <likewise>
Submitted:  Wed 26 Mar 2003 01:55:35 PM UTC
   
 
Category:  pbufs Severity:  1,5
Item Group:  Faulty Behaviour Status:  Wont Fix
Privacy:  Public Assigned to:  likewise
Open/Closed:  Closed Planned Release:  None
lwIP version:  None

Jump to the original submission

Tue 17 Apr 2007 05:48:53 PM UTC, comment #6: 

I've checked in a comment-change for pbuf_realloc():

Changed the comment to pbuf_realloc() that it can't grow (only shrink) chains to reflect the fact that we decided not to change this.

Simon Goldschmidt <goldsimon>
Group administrator
Tue 17 Apr 2007 03:07:34 PM UTC, comment #5: 

I suggest leave it as is.  The limitations are documented (I think) and changing it would have only minor benefit.

Closing this "WONT FIX"


Kieran Mansley <kieranm>
Group Member
Tue 17 Apr 2007 03:03:35 PM UTC, comment #4: 


> Perhaps simply renaming it from pbuf_realloc() to pbuf_trim() or something along those lines would be sufficient to put this one to rest?


That sounds like a good and simple idea to me! But it seems like this could possibly break applications, if they use pbuf_realloc().

Kieran, what do you think?

Simon Goldschmidt <goldsimon>
Group administrator
Tue 17 Apr 2007 02:44:20 PM UTC, comment #3: 

There doesn't seem to be any point to me since you can grow a pbuf chain by simply pbuf_chain()'ing another pbuf, and that would almost certainly be more efficient.

I did happen to notice though that pbuf_realloc uses an s16_t to express the difference in size between the old and new sizes, but you could be e.g. shrinking a 64K pbuf to 16K, which can't be expressed in an s16_t. I'll fix that right now by making it an s32_t.

Jonathan Larmour <jifl>
Group Member
Tue 17 Apr 2007 02:19:09 PM UTC, comment #2: 

Simon says:

>Do we need this? If not, it would only add unnecessary code >lines and binary size...


Well, I'd have to say since we don't have it now, and things are apparently working okay, we must not really need it. ;)

The only real issue I see here is that pbuf_realloc() SOUNDS like it should be able to construct a larger payload area... and it can't, hence the well-documented shortcoming. Why bug #2942 was entered, I don't know... Did Leon want this functionality for some specific purpose?

Perhaps simply renaming it from pbuf_realloc() to pbuf_trim() or something along those lines would be sufficient to put this one to rest?



Jim Pettinato <jim_pettinato>
Group Member
Tue 17 Apr 2007 01:53:54 PM UTC, comment #1: 

Do we need this? If not, it would only add unnecessary code lines and binary size...

Simon Goldschmidt <goldsimon>
Group administrator
Wed 26 Mar 2003 01:55:35 PM UTC, original submission:  


Leon Woestenberg <likewise>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by kieranm (Posted a comment)
  • -email is unavailable- added by jifl (Posted a comment)
  • -email is unavailable- added by jim_pettinato (Posted a comment)
  • -email is unavailable- added by goldsimon (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2007-04-17 kieranm StatusNone Wont Fix
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code