git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Stefan Beller" <stefanbeller@gmail.com>,
	"Arjun Sreedharan" <arjun024@gmail.com>,
	"Git Mailing List" <git@vger.kernel.org>,
	"Christian Couder" <chriscool@tuxfamily.org>,
	"Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>
Subject: Re: [PATCH] bisect: save heap memory. allocate only the required amount
Date: Mon, 25 Aug 2014 09:07:32 -0400	[thread overview]
Message-ID: <20140825130732.GD17288@peff.net> (raw)
In-Reply-To: <CAPc5daWheSH8E-PycSUq2Coqp19t_+_6TuBEOKhK4QwsEtzkkA@mail.gmail.com>

On Sun, Aug 24, 2014 at 04:39:37PM -0700, Junio C Hamano wrote:

> On Sun, Aug 24, 2014 at 8:10 AM, Stefan Beller <stefanbeller@gmail.com> wrote:
> >>       for (p = list, i = 0; i < cnt; i++) {
> >> -             struct name_decoration *r = xmalloc(sizeof(*r) + 100);
> >> +             char name[100];
> >
> > Would it make sense to convert the 'name' into a git strbuf?
> > Please have a look at Documentation/technical/api-strbuf.txt
> 
> Why not go one step further and format it twice, once only
> to measure the necessary size to allocate, allocate and
> then format into it for real? Then you do not need to print
> into a temporary strbuf, copy the result and free the strbuf,
> no?
> 
> BUT.
> 
> The string will always be "dist=" followed by decimal representation of
> a count that fits in "int" anyway, so I actually think use of strbuf is way
> overkill (and formatting it twice also is); the patch as posted should be
> just fine.

I think you are right, and the patch is the right direction (assuming we
want to do this; I question whether there are enough elements in the
list for us to care about the size, and if there are, we are probably
better off storing the int and formatting the strings on the fly).

I wonder if there is a way we could get rid of the magic "100" here,
though. Its meaning is "enough to hold 'dist=' and any integer". But you
have to read carefully to see that this call to sprintf is not a buffer
overflow. A strbuf is one way to get rid of it, though it is awkward
because we then have to copy the result into a flex-array structure.

It would be nice if there was some way to abstract the idea of
formatting a buffer directly into a flex-array. That would involve the
double-format you mention, but we could use it in lots of places to make
the code nicer. Maybe like:

  void *fmt_flex_array(size_t base, const char *fmt, ...)
  {
          va_list ap;
	  size_t flex;
	  unsigned char *ret;

	  va_start(ap, fmt);
	  flex = vsnprintf(NULL, 0, fmt, ap);
	  va_end(ap);

	  ret = xmalloc(base + flex + 1);
	  va_start(ap, fmt);
	  /* Eek, see below */
	  vsnprintf(ret + flex, flex + 1, fmt, ap);

	  return ret;
  }

and you'd call it like:

  struct name_decoration *r = fmt_flex_array(sizeof(*r), "dist=%d", x);

Except that I don't think we are guaranteed that offsetof(mystruct,
flex_member) is equal to sizeof(mystruct). If FLEX_ARRAY is 0, it should
be, but some platforms use FLEX_ARRAY=1. So you'd have to pass in the
offset like:

  struct name_decoration *r = fmt_flex_array(sizeof(*r),
                                             offsetof(*r, name),
					     "dist=%d", x);

which is a little less nice. You could make it nicer with a macro, but
we don't assume variadic macros. <sigh>

-Peff

  reply	other threads:[~2014-08-25 13:08 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-24 14:17 [PATCH] bisect: save heap memory. allocate only the required amount Arjun Sreedharan
2014-08-24 15:10 ` Stefan Beller
2014-08-24 23:39   ` Junio C Hamano
2014-08-25 13:07     ` Jeff King [this message]
2014-08-25 21:36       ` Junio C Hamano
2014-08-26 11:03         ` Jeff King
2014-08-26 11:57           ` Ramsay Jones
2014-08-26 12:14             ` Jeff King
2014-08-26 12:37               ` Ramsay Jones
2014-08-26 12:43                 ` Jeff King
2014-08-26 12:59                   ` Ramsay Jones
2014-08-24 15:32 ` Ramsay Jones
2014-08-24 21:55   ` Arjun Sreedharan
2014-08-25 13:35 ` Jeff King
2014-08-25 14:06   ` Christian Couder
2014-08-25 15:00     ` Jeff King
2014-08-25 18:26       ` Junio C Hamano
2014-08-25 19:35         ` Jeff King
2014-08-25 20:27           ` Arjun Sreedharan
2014-08-25 21:11           ` Junio C Hamano
2014-08-26 10:20             ` [PATCH 0/3] name_decoration cleanups Jeff King
2014-08-26 10:23               ` [PATCH 1/3] log-tree: make add_name_decoration a public function Jeff King
2014-08-26 11:48                 ` Ramsay Jones
2014-08-26 12:17                   ` Jeff King
2014-08-26 10:23               ` [PATCH 2/3] log-tree: make name_decoration hash static Jeff King
2014-08-26 17:40                 ` Junio C Hamano
2014-08-26 17:43                   ` Jeff King
2014-08-26 19:25                     ` Junio C Hamano
2014-08-26 10:24               ` [PATCH 3/3] log-tree: use FLEX_ARRAY in name_decoration Jeff King
2014-08-27  0:30                 ` Eric Sunshine
2014-08-25 21:14 ` [PATCH] bisect: save heap memory. allocate only the required amount Junio C Hamano
2014-08-26  7:30   ` Arjun Sreedharan

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=20140825130732.GD17288@peff.net \
    --to=peff@peff.net \
    --cc=arjun024@gmail.com \
    --cc=chriscool@tuxfamily.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=pclouds@gmail.com \
    --cc=stefanbeller@gmail.com \
    /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).