From: "Christopher Li" <sparse@chrisli.org>
To: David Given <dg@cowlark.com>
Cc: linux-sparse@vger.kernel.org, Bernd Petrovitsch <bernd@firmix.at>
Subject: Re: Pointer arithmetic error
Date: Fri, 27 Jun 2008 11:01:08 -0700 [thread overview]
Message-ID: <70318cbf0806271101n2f9a65buc72764ee97f9ced9@mail.gmail.com> (raw)
In-Reply-To: <48650B35.5040505@cowlark.com>
> In C, there is no type "byte" (unless you typedef oder #define it).
> "byte" is usually (but not necessarily) meant as "unsigned char".
In C spec, there is a concept of "byte". The union return by sizeof()
is byte. Char must fit in a byte. But char does not necessary have the
same bits as byte. Char can have more.
C99: 3.6, 3.7.1
Because char can always fit in byte, sizeof(char) == 1.
> 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.
sizeof() return value measure in _byte_.
C99: 6.5.3.4
On Fri, Jun 27, 2008 at 8:45 AM, David Given <dg@cowlark.com> wrote:
> Bernd Petrovitsch wrote:
> [...]
>>
>> That's the bug. there is no difference between "byte" and "char". Tell
>> it that a char has 32 bits too *if* it's the case.
No, there is a different between "byte" and "char". See above.
>
> Having checked the standard it turns out that we've been talking at cross
> purposes as I've been using the wrong terminology --- it actually defines
> (unhelpfully) that byte and char are the same size. Sorry for the confusion.
>
> What I was referring to when I previously said (erroneously) 'byte' was 'an
> address delta of 1', as understood by the assembler. Let's just call this a
> 'unit' for clarity. This is not necessarily the same size as a char.
In C's term, that is call a "byte" :-)
> I'm proposing adding a bits_in_unit (or something) setting and then going
> through and tracking down these places and changing them to use it. That way
> it should still work fine on exotic architectures like mine.
You are right that point out a bug (assumption) of sparse which byte is 8 bits.
Using bits_in_byte is instead of 8 is better there.
Using bits_in_char assumes char has same bits as byte. That is my read
of the C spec.
Thanks
Chris
next prev parent reply other threads:[~2008-06-27 18:01 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
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 [this message]
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=70318cbf0806271101n2f9a65buc72764ee97f9ced9@mail.gmail.com \
--to=sparse@chrisli.org \
--cc=bernd@firmix.at \
--cc=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).