From: Alex Riesen <raa.lkml@gmail.com>
To: Pierre Habouzit <madcoder@debian.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org
Subject: Re: [PATCH 1/2] Have a filter_start/filter_end API.
Date: Sun, 7 Oct 2007 23:50:41 +0200 [thread overview]
Message-ID: <20071007215041.GB2765@steel.home> (raw)
In-Reply-To: <20071007165218.GE10024@artemis.corp>
Pierre Habouzit, Sun, Oct 07, 2007 18:52:18 +0200:
> So, maybe there is a way to rename strbuf_start_filter so that it's
> more straightforward. The way to use the API is:
>
> @ char *to_free = NULL;
> @ if ((src is inside dst && need_realloc) || operation is not in-place)
> @ to_free = strbuf_detach(dst, NULL);
> @ strbuf_make_room(dst, needed_size);
Why do you have to play these games with src being inside/outside?
Don't you know where src already is? AFAICS in convert.c crlf_to_git -
you do. And everywhere else you know this fact too.
> // do whatever you want with src and dst
>
> free(to_free);
>
> strbuf_start_filter tries to implement the block marked with `@'. Of
> course:
> * need_realloc == (needed_size >= dst->alloc)
> * src is inside dst means:
> src > dst->buf && src < dst->buf + dst->alloc
in convert.c it is never "inside". It is _exactly_ the ->buf.
No need for generic "inside" check. Just test if src == ->buf.
And AFAICS, there is no other users of the function.
> 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?
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):
/* simplified */
int convert_to_git(const char *path, const char *src, size_t len, struct strbuf *dst)
{
int crlf = CRLF_GUESS;
int ident = 0, ret = 0;
char *filter = NULL;
const char *tmp = src;
ret |= apply_filter(path, tmp, len, dst, filter);
if (ret) {
tmp = xmemdupz(dst->buf, dst->len);
len = dst->len;
}
if (crlf_to_git(path, tmp, len, dst, crlf)) {
ret |= 1;
if (tmp != src)
free((void*)tmp);
tmp = xmemdupz(dst->buf, dst->len);
len = dst->len;
}
ret |= ident_to_git(path, tmp, len, dst, ident);
if (tmp != src)
free((void*)tmp);
return ret;
}
It is just to show that nothing like strbuf_start_filter is _needed_
at all.
next prev parent reply other threads:[~2007-10-07 21:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-05 20:19 strbuf `filter' API Pierre Habouzit
[not found] ` <1191615571-15946-2-git-send-email-madcoder@debian.org>
2007-10-06 9:06 ` [PATCH 1/2] Have a filter_start/filter_end API Alex Riesen
2007-10-07 14:53 ` Pierre Habouzit
2007-10-07 16:07 ` Alex Riesen
2007-10-07 16:52 ` Pierre Habouzit
2007-10-07 21:50 ` Alex Riesen [this message]
2007-10-08 7:29 ` Pierre Habouzit
2007-10-08 18:48 ` Alex Riesen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071007215041.GB2765@steel.home \
--to=raa.lkml@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=madcoder@debian.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).