read/write in block device driver
 

Hi
In block device driver, for reading the device I read my device and then copy to buffer array of request structure, but this buffer is defined as char*, what should I do when readed bytes are unsigned char. Is there any way other than request structure for transferring readed bytes to the driver?
Thanks

Size of unsigned char is 1 byte. So, can you pick up
one byte and put in the char*.

memcpy etc. would obviously not work here.

Thanks for your reply, but if we have an unsigned value upper than 128 and cast it to a char variable, then char variable would be corrupted, try below code in linux:

void main(){
char i;
unsigned char j = 0xf1;
i = j;
printf("j=%X,i=%X",j,i);
}

it would print j=f1,i=fffffff1, may be the printed value is corrupted, I don't have any editor to trace it and watch the values in memory.

No, it is not corrupted.

While the C99 standard (section 6.3.1.3) states that casting an unsigned value to signed results in implementation-defined behaviour, all current architectures use two's complement to represent signed integers, so casts between integer types do not modify the bit pattern at all. Conversion to larger type replicates the high bit to new bits, and conversion to smaller type uses only the low bits. Signedness or unsignedness does not affect integer casts at all. In other words, all architectures running Linux have the same behaviour: use the same actual bit pattern. Thus, no corruption.

(As far as I know, this actually extends to all currently mass-produced CPU architectures. There are some historical ones that used one's complement, and thus have +0 and -0 with differing bit patterns, but they have a lot of other weirdnesses too. You can safely assume all architectures use two's complement signed integers, and that casting between signed and unsigned integer types of the same size does not modify the bit patterns.)

Your example code has a fatal flaw: both i and j are converted to int first. Because usually i is a signed type, for it the new high bits will be duplicates of the old highest bit (the sign bit, in two's complement format). Because j is unsigned, the new high bits will be zero.

Try this code instead:
The output will be
except that the number of consecutive f's in the c1 and s1 lines depends on the size of int on the architecture (32 bits in Linux, always, as far as I know).

This output will show you that casting does not affect the bit pattern, and that the bit pattern in the signed char is exactly the same as the bit pattern in the unsigned char. Thus, casting between signed and unsigned types in Linux, never changes the actual bits. Only their interpretation.

Thanks for your complete fully-described reply:) I got it