public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: Matthieu Moy <Matthieu.Moy@grenoble-inp•fr>
To: William <william.duclot@ensimag•grenoble-inp.fr>
Cc: Junio C Hamano <gitster@pobox•com>,
	git@vger•kernel.org, simon.rabourg@ensimag•grenoble-inp.fr,
	francois.beutin@ensimag•grenoble-inp.fr,
	antoine.queru@ensimag•grenoble-inp.fr, mhagger@alum•mit.edu
Subject: Re: [PATCH 2/2] strbuf: allow to use preallocated memory
Date: Tue, 31 May 2016 17:54:59 +0200	[thread overview]
Message-ID: <vpq4m9eql2k.fsf@anie.imag.fr> (raw)
In-Reply-To: <20160531154503.GA24895@Messiaen> (William's message of "Tue, 31 May 2016 17:45:03 +0200")

William <william.duclot@ensimag•grenoble-inp.fr> writes:

> On Mon, May 30, 2016 at 11:34:42PM -0700, Junio C Hamano wrote:
>
>> As long as your "on stack strbuf" allows lengthening the string
>> beyond the initial allocation (i.e. .alloc, not .len), the user of
>> the API (i.e. the one that placed the strbuf on its stack) would not
>> know when the implementation (i.e. the code in this patch) decides
>> to switch to allocated memory, so it must call strbuf_release()
>> before it leaves.  Which in turn means that your implementation of
>> strbuf_release() must be prepared to be take a strbuf that still has
>> its string on the stack.
>
> Well, my implementation does handle a strbuf that still has its
> string on the stack: the buffer won't be freed in this case (only a
> reset to STRBUF_INIT).
> Unless I misunderstood you?

I think Junio meant:

void f()
{
	struct strbuf sb;
	char buf[N];
	strbuf_wrap_preallocated(&sb, buf, ...);
	strbuf_add(&sb, ...);

	// is it safe to just let sb reach the end of its scope?
}

To answer the last question, the user would need to know too much about
the allocation policy, so in this case the user should call
strbuf_release(), and let it chose whether to call "free()"
(OWNS_MEMORY) or not. This is OK with your implementation, but the doc
needs to reflect this.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

  reply	other threads:[~2016-05-31 15:55 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-30 10:36 [PATCH 0/2] strbuf: improve API William Duclot
2016-05-30 10:36 ` [PATCH 1/2] strbuf: add tests William Duclot
2016-05-30 11:26   ` Johannes Schindelin
2016-05-30 13:42     ` Simon Rabourg
2016-05-30 11:56   ` Matthieu Moy
2016-05-31  2:04   ` Michael Haggerty
2016-05-31  9:48     ` Simon Rabourg
2016-05-30 10:36 ` [PATCH 2/2] strbuf: allow to use preallocated memory William Duclot
2016-05-30 12:13   ` Johannes Schindelin
2016-05-30 13:20     ` William Duclot
2016-05-31  6:21       ` Johannes Schindelin
2016-05-31  3:05     ` Michael Haggerty
2016-05-31  6:41       ` Johannes Schindelin
2016-05-31  8:25         ` Michael Haggerty
2016-05-30 12:52   ` Matthieu Moy
2016-05-30 14:15     ` William Duclot
2016-05-30 14:34       ` Matthieu Moy
2016-05-30 15:16         ` William Duclot
2016-05-31  4:05     ` Michael Haggerty
2016-05-31 15:59       ` William Duclot
2016-06-03 14:04       ` William Duclot
2016-05-30 21:56   ` Mike Hommey
2016-05-30 22:46     ` William Duclot
2016-05-30 22:50       ` Mike Hommey
2016-05-31  6:34   ` Junio C Hamano
2016-05-31 15:45     ` William
2016-05-31 15:54       ` Matthieu Moy [this message]
2016-05-31 16:08         ` William Duclot
2016-05-30 11:32 ` [PATCH 0/2] strbuf: improve API Remi Galan Alfonso
2016-06-01  7:42   ` Jeff King
2016-06-01 19:50     ` David Turner
2016-06-01 20:09       ` Jeff King
2016-06-01 20:22         ` David Turner
2016-06-01 21:07     ` Jeff King
2016-06-02 11:11       ` Michael Haggerty
2016-06-02 12:58         ` Matthieu Moy
2016-06-02 14:22           ` William Duclot
2016-06-24 17:20         ` Jeff King

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=vpq4m9eql2k.fsf@anie.imag.fr \
    --to=matthieu.moy@grenoble-inp$(echo .)fr \
    --cc=antoine.queru@ensimag$(echo .)grenoble-inp.fr \
    --cc=francois.beutin@ensimag$(echo .)grenoble-inp.fr \
    --cc=git@vger$(echo .)kernel.org \
    --cc=gitster@pobox$(echo .)com \
    --cc=mhagger@alum$(echo .)mit.edu \
    --cc=simon.rabourg@ensimag$(echo .)grenoble-inp.fr \
    --cc=william.duclot@ensimag$(echo .)grenoble-inp.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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