Pierre Habouzit, Mon, Oct 08, 2007 09:29:47 +0200: > 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. > > 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
