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@xxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html