git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Alex Riesen <raa.lkml@gmail.com>
Date
Oct 8, 2007, 18:48 UTC
Message-ID
<20071008184831.GB3123@steel.home>
In-Reply-To
<20071008072947.GB22552@artemis.corp>
Pierre Habouzit, Mon, Oct 08, 2007 09:29:47 +0200:
Show 15 quoted lines
> 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

update the outside pointer you can. But I actually lost all interest: personally I never use the filters and deeply despise the reasons caused their existence.

Show 12 quoted lines
> > 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.

I take this suggestion back. Do not use memdup, as it is slow, requires lots of memory and may fragment heap. Sorry for repeating.

> Given how you try to micro-optimize strbuf_cmp I'm a bit lost here…
> 

I didn't. It just happened. If I _wanted_ to optimize anything I wouldn't start with a function which is used exactly one time in a program with a name like "rerere" which is not even used in default configuration.

Previous: Pierre Habouzit
Message 8 of 8 in “strbuf `filter' API”
  1. Pierre HabouzitOct 5, 2007
  2. Alex RiesenOct 6, 2007
  3. Pierre HabouzitOct 7, 2007
  4. Alex RiesenOct 7, 2007
  5. Pierre HabouzitOct 7, 2007
  6. Alex RiesenOct 7, 2007
  7. Pierre HabouzitOct 8, 2007
  8. Alex RiesenOct 8, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.