Re: [PATCH 1/2] Have a filter_start/filter_end API.

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

 



On Sun, Oct 07, 2007 at 09:50:41PM +0000, Alex Riesen wrote:
> Pierre Habouzit, Sun, Oct 07, 2007 18:52:18 +0200:
> > Though, those are both things that I find ugly to "know" in convert.c.
> > How things are allocated in strbufs is one of the few things we don't
> > want to assume anywhere outside of the strbuf module.
>
> src is outside of strbuf scope. It is not internal to struct strbuf.
> The caller must already know if it is inside of the given strbuf
> instance.
>
> need_realloc is covered by make_room, isn't it?

  Internally yes, but make_room may move the buffer, if that happens,
there is nothing we can do, in the case where we point inside (or at the
begining of - fwiw it's the same here) the buffer

> I'd suggest just fix the caller, it is simple in convert.c: just use
> ret, which contains exactly this information. If you insist on editing
> in-place, which makes your routines really need the in-placeability
> informaion. Just give it to them, better explicitely. All of this
> makes the routines very convert.c specific, which is the reason why I
> argument to have them just there and nowhere else.
> 
> Alternatively, one can memdup ->buf (as it is the input for next
> filter) every time a filter modifies it (which is safe, but simple,
> slow, requires memory, and may fragment heap):

  This is exactly what we are trying to avoid with the current form.
Given how you try to micro-optimize strbuf_cmp I'm a bit lost here…

-- 
·O·  Pierre Habouzit
··O                                                madcoder@xxxxxxxxxx
OOO                                                http://www.madism.org

Attachment: pgpnHgsAud8yl.pgp
Description: PGP signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux