The reason pointer arithmetic is
scaled for the base type is simply to support array operations.
Given
int x[2];
... we access the
second element of the array by writing x[1] or equivalently *(x + 1). You cannot fully separate arrays and pointers because the value of an array is a pointer to its first element, such that most array operations will involve pointers to their elements. It would be quite inconvenient and error-prone if we had to multiply the element number with the base type size to access the element.
Quote:
for chars if i do a="a" then get the address (&a) i get some large negative number, but i know the size of a char is 1 byte or 8 bits, so shouldn't the value be between 0 and 255 ?
also if converting an address of an int to hex and printing it why is it never negative?
The address of your char has a different type - it's char *, not char - and will probably (but not necessarily) have the same size as any other pointer, and typically amounts to 32 or 64 bits on most systems.
Signedness is a matter of how the data is interpreted. The %x format specifier expects an
unsigned argument and will therefore treat all bits as data, whereas if you're using %d, the most significant bit of your value will be treated as sign bit - if it's set, the number is negative, otherwise it isn't.
Pointer encoding is system-specific, but it is generally not signed, so you should not print it as a signed value.
Quote:
I think it's reasonably portable among 32-bit and 64-bit varieties of UNIX, and 32-bit varieties of Windows. Perhaps not 64-bit windows, in which long inexplicably doesn't change size even though the integer width of the processor doubles...
On Windows (and arguably other systems as well, though I tend to use unsigned long) it is best to convert your pointer to size_t, because that will give you an __int64.