All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Given <dg@cowlark.com>
To: linux-sparse@vger.kernel.org
Subject: Re: Pointer arithmetic error
Date: Fri, 27 Jun 2008 11:55:12 +0100	[thread overview]
Message-ID: <4864C710.8000208@cowlark.com> (raw)
In-Reply-To: <1214560196.20755.73.camel@tara.firmix.at>

Bernd Petrovitsch wrote:
[...]
> In C, there is no type "byte" (unless you typedef oder #define it).
> "byte" is usually (but not necessarily) meant as "unsigned char".

The issue here is that sparse is helpful and converts pointer offsets 
into byte offsets when generating code for pointer arithmetic. So:

const int* p = (const char*) 1234;
p += 10;

-->

set.32 %p0 <- 1234
add.32 %p1 <- %p0, 40
(In fact, in this example it'd collapse these together and use 1274 
instead.)

This appears to be done using hard-coded knowledge that a byte (one unit 
of addressingness) is 8 bits wide.

Chris Li wrote:
> Byte need to big enough to hold the char. Using bits_in_byte is better.
> There might be other place in sparse assume byte is 8 bits.

IIRC C specifies that sizeof() returns values measured in chars, but I 
don't believe it specifies any mapping between the size of chars and the 
underlying addressing units --- it should be possible to use 16-bit 
chars, for example, on an 8-bit byte system. Using 32-bit ints, 
sizeof(int) would then return 2; but you wouldn't be able to access 
individual bytes from C.

That's assuming I've remembered the spec correctly, of course --- this 
stuff is annoying subtle.

If you like I'll go and have a look to see if this can be easily fixed 
--- I need to do it anyway. In fact, I have vague recollections that 
load and store were actually using offsets like 0, 1, 2, etc (the 
'right' values), which means they must have been using bits_per_char to 
do their calculations; I need to check up on this.

-- 
David Given
dg@cowlark.com

  reply	other threads:[~2008-06-27 10:55 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-26 23:40 Pointer arithmetic error David Given
2008-06-26 23:51 ` Chris Li
2008-06-27  0:17   ` David Given
2008-06-27  9:00     ` Christopher Li
2008-06-27  9:49     ` Bernd Petrovitsch
2008-06-27 10:55       ` David Given [this message]
2008-06-27 11:20         ` Bernd Petrovitsch
2008-06-27 14:03           ` David Given
2008-06-27 14:45             ` Bernd Petrovitsch
2008-06-27 15:45               ` David Given
2008-06-27 18:01                 ` Christopher Li
2008-06-27 23:32                   ` David Given
2008-06-28  0:17                     ` Christopher Li
2008-06-28  0:23                       ` David Given
2008-06-29  0:10                       ` David Given
2008-06-28  0:29                     ` Josh Triplett
2008-06-29  0:13                     ` Tommy Thorn
     [not found]                     ` <48658B28.6010301@numba-tu.com>
2008-06-29  0:30                       ` David Given
2008-06-29  0:38                         ` Tommy Thorn
2008-06-29 12:19                   ` Bernd Petrovitsch

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=4864C710.8000208@cowlark.com \
    --to=dg@cowlark.com \
    --cc=linux-sparse@vger.kernel.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.