git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Pierre Habouzit <madcoder@debian.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: Use of strbuf.buf when strbuf.len == 0
Date: Thu, 27 Sep 2007 13:22:04 +0200	[thread overview]
Message-ID: <20070927112204.GE10289@artemis.corp> (raw)
In-Reply-To: <7vir5wy6fv.fsf@gitster.siamese.dyndns.org>

[-- Attachment #1: Type: text/plain, Size: 1218 bytes --]

On Thu, Sep 27, 2007 at 06:21:24AM +0000, Junio C Hamano wrote:
> It would be appreciated if somebody with a fresh pair of eyes
> can go over the strbuf series one more time to make sure that we
> do not try to blindly use buf.buf, assuming buf.buf[0] is NUL if
> (buf.len == 0).

  Like said in the 2/2 patch, I think it's better if people could be
able to always assume that and be done with it, else you have to know
this internal duality of the empty strbuf and it sucks.

  Instead, what is important, is that people that initialized a strbuf,
then want to go back in the char* world gets a NULL if nothing was
allocated. It is a semantics that is used in a few places (it's arguable
that it's a right thing to assume though). For those, making
strbuf_detach use mandatory, and dealing with the special ->alloc == 0
case is the easiest way.

  And as I don't trust my eyes to be fresh, I've used the aid of the
compiler to bust any place where we were using .buf members directly,
possibly doing something stupid.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  parent reply	other threads:[~2007-09-27 11:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-27  6:21 Use of strbuf.buf when strbuf.len == 0 Junio C Hamano
2007-09-27 10:13 ` Pierre Habouzit
2007-09-27 10:51   ` [PATCH 1/2] double free in builtin-update-index.c Pierre Habouzit
2007-09-27 10:58   ` [PATCH 2/2] strbuf change: be sure ->buf is never ever NULL Pierre Habouzit
2007-09-29  0:51   ` Use of strbuf.buf when strbuf.len == 0 Linus Torvalds
2007-09-29  7:48     ` Pierre Habouzit
2007-09-27 11:22 ` Pierre Habouzit [this message]
2007-09-27 11:33   ` [PROPER PATCH 1/1] Make read_patch_file work on a strbuf Pierre Habouzit
2007-09-27 11:33   ` [PATCH " Pierre Habouzit
2007-09-27 11:37   ` Use of strbuf.buf when strbuf.len == 0 Pierre Habouzit

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070927112204.GE10289@artemis.corp \
    --to=madcoder@debian.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).