On Fre, 2008-06-27 at 15:03 +0100, David Given wrote: > Bernd Petrovitsch wrote: > > It is done IMHO with the false knowledge that "sizeof(int) == 4 * > > sizeof(char)". > > No, it's correctly been told that ints are 32 bits wide, but then it's > converting this to *bytes* (not chars) by dividing by the hard-coded 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. > constant 8. Why do you (or sparse) want to divide a the size of a type where "sizeof(type) == 1"? Use (a correct) CHAR_BIT for that. > (By 'byte' I'm referring to the quantum of addressingness of the > underlying machine architecture. In other words, the numbers that are > used as parameters as offsets into load and store. This isn't something > that's exposed to C except on architectures where sizeof(byte) == > sizeof(char), i.e., all sensible ones.) Such hardware-specific issues must be implemented by the compiler. So you probably have to extend "sparse" for that feature. > [...] > > 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? > We're dealing with things from the machine code perspective, where > sizeof(byte) == 1, and sizeof(char) is not necessarily the same as > sizeof(byte). And that's AFAIU the problem: "sizeof(char) == 1" in C (K&R, c8x, c99) per definitionem. There is no way around it. For all architectures in the world, past, present and future. If your hardware has 32bit char, short and int types, there is no way in C to define a "byte" in a somewhat sane way. Yes, there are bitfields but that tend to get somewhat clumsy. Perhaps the are some compiler-specific extensions for such strange hardware. But then you leave the defined ground and need to implement them into "sparse" too. > I find it really helps with this stuff if you are capable of holding two > completely contradictory beliefs at the same time. A certain level of I'm just pointing out the view of "C" (or what I understand it is). Since "sparse" is a C code parser, this should matter most (if not all and only) IMNSHO. I don't think the (above newly beyond "C" introduced) concept of "byte" for your specific, unknown and secret CPU/architecture is helpful in any way. > insanity can help too... Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- 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
