public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Jesper Juhl <juhl-lkml@dif.dk>
Cc: "Richard B. Johnson" <linux-os@analogic.com>,
	Andrew Morton <akpm@osdl.org>,
	David Mosberger-Tang <davidm@hpl.hp.com>,
	Stephane Eranian <eranian@hpl.hp.com>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [resend][PATCH] avoid signed vs unsigned comparison in efi_range_is_wc()
Date: Thu, 16 Jun 2005 23:32:01 +0200	[thread overview]
Message-ID: <200506162332.02655.arnd@arndb.de> (raw)
In-Reply-To: <Pine.LNX.4.62.0506162306300.2477@dragon.hyggekrogen.localhost>

On Dunnersdag 16 Juni 2005 23:07, Jesper Juhl wrote:
> > 
> > Well long and int are the same size on ix86. What you really need
> > is 'size_t' for counters. That's the largest unsigned integer that
> > will fit in a register on the target platform. It is platform-
> > specific, therefore defined in stddef.h. No index or return-value
> > is supposed to be larger than what can be represented in size_t,
> > therefore it is a good type to use.
> > 
> > Note that on 64-bit platforms, size_t will be larger than an unsigned
> > int. This is good.
> > 
> Good info, thanks Richard.

Actually not that good. size_t is meant to represent the size of a structure
or array in units of characters. It also happens to be the same size as an
integer register on all architectures that Linux supports, just like unsigned
long.

The most common convention in the kernel is to use 'unsigned long' for
every integer that needs to be as large as possible without the overhead
of strict 64 bit types (like here), and also for integer values that need
to be the same size as a pointer.

OTOH size_t should be used only to count bytes, like in standard C usage.

	Arnd <><

  reply	other threads:[~2005-06-16 21:35 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-16 20:21 [resend][PATCH] avoid signed vs unsigned comparison in efi_range_is_wc() Jesper Juhl
2005-06-16 20:41 ` Andrew Morton
2005-06-16 21:02   ` Jesper Juhl
2005-06-16 21:48     ` Arnd Bergmann
2005-06-16 22:24       ` Jesper Juhl
2005-06-16 20:45 ` Richard B. Johnson
2005-06-16 21:07   ` Jesper Juhl
2005-06-16 21:32     ` Arnd Bergmann [this message]
2005-06-16 21:01 ` David Mosberger
2005-06-20 17:00   ` Jesse Barnes
  -- strict thread matches above, loose matches on Subject: below --
2005-06-17  0:25 Arnd Bergmann <arnd@arndb.de>
2005-06-17 17:04 ` Jesper Juhl

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=200506162332.02655.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=akpm@osdl.org \
    --cc=davidm@hpl.hp.com \
    --cc=eranian@hpl.hp.com \
    --cc=juhl-lkml@dif.dk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-os@analogic.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