> [EMAIL PROTECTED] said:
> I go this from some mailing list ... dont know if it helps but for what it is
> worth ...
>
> In C, a char is a kind of integer, and so there is such a thing as an "unsigned
>char".
>
> In C, "char" can mean either "unsigned char" or "signed char",
> depending on the platform. (Unlike other kinds of integers, which are
> always signed by default.) The ANSI standard added the "signed"
> keyword so you could talk about signed chars on architectures where the
> default char was unsigned.
Signed or unsigned has to do with the way the high order bit is interpreted
when displaying the value or doing arithmetic operations. On a 32 bit
architecture there is typically 3 "integer" types:
char - 1 byte
short int - 2 bytes
int - 4 bytes
A signed character treats the high order bit of the byte as the sign bit.
Same for an int and a long int, except the length is 2 or 4 bytes respectively.
Most modern computers use 2's complement arithmetic. A few examples suffices asto how
that works.
A signed char with a value of 3 is represented in binary as:
00000011
A -3 is represented as:
11111101
To negate a number, take the bitwise complement of the number and
add a 1 to the number. Any carryover is discarded. This system has the nice
property that you can add any two numbers (positive or negative) and get the
correct result. So a "signed char" has a value range of:
-128 <= n <= 127
The -128 is a bit of an oddball, since its 8 bit representation is
10000000
If you complement it in 8 bits you get the same 8 bit value. So the arithmetic
logic needs to account for this seeming anomoly.
In perl you usually do not have to worry about the internal representation of
integers. However, if you need to pack a structure, you do need to be mindful
of the underlying hardware representation.
--
Smoot Carl-Mitchell
Consultant
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
