All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre Habouzit <madcoder@debian.org>
To: "René Scharfe" <rene.scharfe@lsrfire.ath.cx>
Cc: "Shawn O. Pearce" <spearce@spearce.org>, git@vger.kernel.org
Subject: Re: [PATCH 2/2] Correct some sizeof(size_t) != sizeof(unsigned long)  typing errors
Date: Sun, 21 Oct 2007 12:31:32 +0200	[thread overview]
Message-ID: <20071021103132.GA25741@artemis.corp> (raw)
In-Reply-To: <471B1AA5.8070009@lsrfire.ath.cx>

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

On Sun, Oct 21, 2007 at 09:23:49AM +0000, René Scharfe wrote:
> > Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> > ---
> >  builtin-apply.c   |    2 +-
> >  builtin-archive.c |    2 +-
> >  diff.c            |    4 ++--
> >  entry.c           |    2 +-
> >  strbuf.h          |    8 +++++++-
> >  test-delta.c      |    3 ++-
> >  6 files changed, 14 insertions(+), 7 deletions(-)
> 
> I have a feeling this is going in then wrong direction.  Shouldn't
> we rather use size_t everywhere?  malloc() takes a size_t, and it's
> the basis of strbuf and also of the file content functions.

  I agree, Junio was working on a patch that generalized use of size_t's
when unsigned long where used and size_t meant, I suppose he didn't had
the time to push it.

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

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

  reply	other threads:[~2007-10-21 10:31 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-21  5:25 [PATCH 2/2] Correct some sizeof(size_t) != sizeof(unsigned long) typing errors Shawn O. Pearce
2007-10-21  9:23 ` René Scharfe
2007-10-21 10:31   ` Pierre Habouzit [this message]
2007-10-22  4:00     ` Shawn O. Pearce

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=20071021103132.GA25741@artemis.corp \
    --to=madcoder@debian.org \
    --cc=git@vger.kernel.org \
    --cc=rene.scharfe@lsrfire.ath.cx \
    --cc=spearce@spearce.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.