Wolfgang Denk wrote:
In message 4731ECA0.1010502@schweigstill.de you wrote:
Wolfgang Denk schrieb:
Oops? I can't parse that. What's the difference between "signed char" and "int" except the number of bits?
Like mentioned before, accessing data via a (signed|unsigned|.) char * is independant of the processor endianess. If you want to read a
Correct. And storing the result in an "int" type is independent of the byte order as well,if you do it right.
bitstream which is bytewise formatted you don't want to care about endianess. Or do you also want some endianess string definitions?
What has this to do with what we're discussing?
And it is even worse; on some architectures, like ARM, it is not allowed to do a 16/32 bit memory access on a non-aligned address, e.g.:
Nobody intended to do that.
int val; int * p_data;
STOP! I asked why we cannot change "val" into an "int". I never said anything about using an "int *" to access to buffer data.
This is the main misunderstanding. When you said "int" I though you meant dereferencing an "int *", in fact not only me but other people on the list as well. So your proposal is to convert the "char val" to an "int val". You don't solve the problem I mentioned by doing this.
This is the current code:
********************* unsigned char *data = ...; char val; int i;
...
val = data [bytecount ++]; i = 8; do { ... write(..., (val < 0), ...); ... val <<= 1; i-- } while (i > 0);
*********************
Let us not forget that all we want to do here is take the *bits* of the buffer one by one, starting from the MSB. Checking for negativity is just a hack to acquire the MSB, since signed values are two's complement.
This code works on all platforms in which "char" defaults to "signed char", because storing a byte from an "unsigned char *" to a "char" will implicitly convert it to a negative value. On ARM, this fails, becuase "char" is also "unsigned char", thus "val<0" is always zero.
Your proposed solution also fails. Just converting the "char val" to an "int val", will never produce a negative value in any architecture. This integer will always be positive.
To avoid a new series of misunderstandings, you said "if you do it right" when you talked about the "int". This could be interpreted as some kind of cast so that the "int val" is negative on all architectures, but I fail to see how this is cleaner than converting the val to "unsigned char" like the "data" and doing "val & 0x80".
-- Angelos Manousaridis