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).

Submitted by:  Leon Woestenberg <likewise>
Submitted on:  Wed 26 Mar 2003 01:55:35 PM UTC  
 
Category: pbufsSeverity: 1,5
Item Group: Faulty BehaviourStatus: Wont Fix
Privacy: PublicAssigned to: Leon Woestenberg <likewise>
Open/Closed: ClosedPlanned Release: None
lwIP version: None

(Jump to the original submission 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>
Project 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>
Project Administrator
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>
Project 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>
Project 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>
Project 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>
Project Administrator
Wed 26 Mar 2003 01:55:35 PM UTC, original submission:
Leon Woestenberg <likewise>
Project MemberIn charge of this item.

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 17 Apr 2007 03:07:34 PM UTCkieranmStatusNone=>Wont Fix
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1