Re: Pointer arithmetic error

[David Given <dg@cowlark.com>]

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.

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.

[...]
>>> ACK. Therefore "sizeof(char) == 1" must always hold.
>> Yes; but that is only true from C's perspective.
> 
> Is there another remotely relevant perspective (let alone more
> important) in a C parser?

The issue here is that sparse is not just a C parser. It is also a 
compiler, and needs to know how to manipulate addresses that are 
represented as units. (This is why I'm using it for my project.) It has 
to be able to express an offset into a structure in units to pass on to 
the 'assembler' (with stock sparse, this is the human who's reading the 
output of test-linearise).

Currently I believe that some parts of sparse are assuming that a unit 
is 8 bits, and other parts are assuming that a unit is CHAR_BITS bits, 
neither of which is necessarily correct. However, I need to go and check 
up on this; I'm away from the machine with my project on it right now.

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.

(Wikipedia has a rather interesting table of machines with interesting 
word/byte/char sizes:

http://en.wikipedia.org/wiki/Word_(computing)#Table_of_word_sizes

The last machine with a freaky word size was the Cray C-90 in 1991, 
where a unit was 64 bits but a char was 8 bits...)

-- 
David Given
dg@cowlark.com