From: Pierre Habouzit <madcoder@debian.org>
To: Jan Wielemaker <wielemak@science.uva.nl>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: size_t vs "unsigned long"
Date: Wed, 03 Oct 2007 23:36:01 +0200 [thread overview]
Message-ID: <20071003213601.GD28188@artemis.corp> (raw)
In-Reply-To: <200710032320.00263.wielemak@science.uva.nl>
[-- Attachment #1: Type: text/plain, Size: 1834 bytes --]
On Wed, Oct 03, 2007 at 09:19:59PM +0000, Jan Wielemaker wrote:
> On Wednesday 03 October 2007 22:48, Pierre Habouzit wrote:
> > On Wed, Oct 03, 2007 at 08:30:04PM +0000, Junio C Hamano wrote:
> > > Traditionally, inside git, we have used the length of things
> > > with "unsigned long" for pretty much anything, except where we
> > > wanted the length exactly sized we used int32_t, uint64_t and
> > > friends.
> > >
> > > A few places pass pointer to unsigned long as the second
> > > parameter to strbuf_detach(), triggering type mismatch warnings.
> > > An easy way out is to change strbuf_detach() to take a pointer
> > > to ulong but I think it is going backwards. Most places that
> > > use "unsigned long" can safely be converted (and made more
> > > correct) to use size_t.
> >
> > Well, afaict, on every linux archs I know of, unsigned longs and
> > size_t are the same. Though, I don't know if that holds for the msys
> > port, and if that does not holds, then a s/unsigned long/size_t/ would
> > help them. Else, for consistency sake, I believe the change is a good
> > one.
>
> Surely on the Microsoft 64-bit compilers size_t is 64-bits and long is
> 32-bits. Don't blame me, I'm just the messenger that learned the hard
> way ...
Yeah, I've been wondering, and it's the information I had. well, the
information I had is that sizeof(size_t) is 4 on win32, and 8 on win64,
OTOH (and this one I'm sure), on windows, longs are 32bits on both (32
and 64 bits ABIs).
So replacing unsigned long with size_t's will help the msys port,
hence I had some insight that this could prove useful, now I'm sure :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2007-10-03 21:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-03 20:30 size_t vs "unsigned long" Junio C Hamano
2007-10-03 20:48 ` Pierre Habouzit
2007-10-03 21:05 ` Junio C Hamano
2007-10-03 21:19 ` Jan Wielemaker
2007-10-03 21:36 ` Pierre Habouzit [this message]
2007-10-04 7:16 ` Jan Wielemaker
2007-10-03 21:36 ` Florian Weimer
2007-10-05 6:27 ` Kyle Moffett
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=20071003213601.GD28188@artemis.corp \
--to=madcoder@debian.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=wielemak@science.uva.nl \
/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.