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
next prev parent 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.