git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Carlos Rica" <jasampler@gmail.com>
To: "Junio C Hamano" <gitster@pobox.com>
Cc: git@vger.kernel.org,
	"Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
	"Kristian Høgsberg" <krh@redhat.com>
Subject: Re: [PATCH] Rename read_pipe() with read_fd() and make its buffer nul-terminated.
Date: Wed, 18 Jul 2007 17:40:09 +0200	[thread overview]
Message-ID: <1b46aba20707180840l6c12fecfy4c610fe3a1a36c5e@mail.gmail.com> (raw)
In-Reply-To: <7vps2q6tjf.fsf@assigned-by-dhcp.cox.net>

2007/7/18, Junio C Hamano <gitster@pobox.com>:
>
> >       unsigned long size = *return_size;
> >       ssize_t iret;
> >       unsigned long off = 0;
> >
> > +     if (!buf || size <= 1) {
> > +             size = alloc_nr(size);
> > +             buf = xrealloc(buf, size);
> > +     }
> > +
>
> Hmph.  The reason this is not "!size" is because you would want
> more than one.  As your plan is to use this mostly for the -F
> option of "tag/commit", I suspect using a bit larger default,
> such as 80 (just a line), or probably 1k (most log messages
> would fit in such a buffer), would be more practical.

The true reason is because I before tried using (size-1) instead of (size)
in xread(..., size - off), and then I forgot to remove that condition. Sorry.

>
> >       do {
> >               iret = xread(fd, buf + off, size - off);
> >               if (iret > 0) {
> >                       off += iret;
> >                       if (off == size) {
> > -                             size *= 2;
> > +                             size = alloc_nr(size);
> >                               buf = xrealloc(buf, size);
> >                       }
> >               }
> >       } while (iret > 0);
> >
> > +     if (off == size)
> > +             buf = xrealloc(buf, size + 1);
> > +     buf[off] = '\0';
> > +
>
> I wonder if doing xread(... (size-1) - off) in the loop would
> ensure (off <= size-1) here.  You also would need to update the
> realloc condition inside loop if you do so.

I have chosen that solution to leave the code easy to read, but the
(size-1) version will avoid that additional (but non-frequent) realloc.

I will resend the fixed patch along with the builtin-tag.c one.

  reply	other threads:[~2007-07-18 15:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-18  7:08 [PATCH] Rename read_pipe() with read_fd() and make its buffer nul-terminated Carlos Rica
2007-07-18  7:49 ` Junio C Hamano
2007-07-18 15:40   ` Carlos Rica [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-07-18 18:31 Carlos Rica

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=1b46aba20707180840l6c12fecfy4c610fe3a1a36c5e@mail.gmail.com \
    --to=jasampler@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=krh@redhat.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).