[asterisk-dev] [svn-commits] lmadsen: branch 1.8 r300082 - /branches/1.8/pbx/pbx_dundi.c

[Tilghman Lesher]

On Monday 03 January 2011 13:36:34 Russell Bryant wrote:
> On Mon, 2011-01-03 at 10:18 -0600, Tilghman Lesher wrote:
> > On Monday 03 January 2011 08:53:19 Olle E. Johansson wrote:
> > > 3 jan 2011 kl. 14.14 skrev SVN commits to the Digium repositories:
> > > > Author: lmadsen
> > > > Date: Mon Jan  3 07:14:25 2011
> > > > New Revision: 300082
> > > > 
> > > > URL: http://svnview.digium.com/svn/asterisk?view=rev&rev=300082
> > > > Log:
> > > > Increase side of mapping response field.
> > > 
> > > I am aware that there's no clear policy for 1.8, but it is in fact
> > > released. This doesn't seem like a bug fix, unless your own
> > > documentation is a reported bug. I don't see a reference to a
> > > reviewboard discussion or anything either...
> > 
> > Agreed.  In addition, our policy when we have fields like this that
> > are too small (and there's only one per structure) is to swap the
> > element to the last item and vary the malloc to cover the size of the
> > string.  Just increasing the buffer size ensures that we still have
> > the limitation, only a bigger one and also wastes a fair amount of
> > memory for the common case.
> 
> Our policy?  Is that written anywhere?  (Hint: it isn't)
> 
> Anyway, that type of change has a higher risk of regression than simply
> increasing the buffer size.  If someone would like to improve that
> structure for trunk, the usage of stringfields would be welcome.

Okay, it's so common of a practice that it probably should be policy.
There's no benefit to using stringfields if the value does not change past
creation.

-- 
Tilghman