Addressing in Xcode for C

Question

I get this output when I compile the code below on 64-bit Intel in Xcode.

#include<stdio.h> #include<limits.h> int main(void) { /* declare some integer variables */ long a = LONG_MAX; long b = 2L; long c = 3L; /* declare some floating-point variables */ double d = 4.0; double e = 5.0; double f = 6.0; printf("A variable of type long occupies %d bytes.", sizeof(long)); printf("\nHere are the addresses of some variables of type long:"); printf("\nThe address of a is: %p The address of b is: %p", &a, &b); printf("\nThe address of c is: %p", &c); printf("\nThe address of ab is: %ld\nvalue of a is %ld\nValue of b is %ld\nsize of pointer %ld ", (&a-&c),a,b,sizeof(&a)); printf("\n\nA variable of type double occupies %d bytes.", sizeof(double)); printf("\nHere are the addresses of some variables of type double:"); printf("\nThe address of d is: %p The address of e is: %p", &d, &e); printf("\nThe address of f is: %p\n", &f); printf("\n size long - %d", sizeof(a)); return 0; } 

  A variable of type long occupies 8 bytes.

 Here are the addresses of some variables of type long:

 The address of a is: 0x7fff5fbff880 
 The address of b is: 0x7fff5fbff878 
 The address of c is: 0x7fff5fbff870 
 The address of ab is: 2

 value of a is 9223372036854775807 
 Value of b is 2 
 size of pointer 8 

 A variable of type double occupies 8 bytes.

 Here are the addresses of some variables of type double:

 The address of d is: 0x7fff5fbff868 
 The address of e is: 0x7fff5fbff860 
 The address of f is: 0x7fff5fbff858 
 size long - 8

It is strange that the difference between the address for a and b is only 2. I expect it to be 8, which will correspond to the number of bytes over time. Does anyone know the reason why this would be?

---

I had a typo in the code where I read & a- & c, but that really doesn't apply to my question. My question is, why is there only a difference of 2 bytes from the variable address to the address of variable b when the length is 8 bytes long, and I expect to see a difference of 8?

Answer 1

Difference in units of sizeof(long) . To make it accept the difference in bytes, you must first specify both pointers:

 ((char *)&a-(char *)&b) 

So the difference in units of sizeof(char) , which is the number of bytes

Answer 2

Pointer arithmetic is based on the size of the type that it does not point to bytes, this link to Pointer Arithmetic describes the topic well, you also have a typo

 (&a-&c) 

you are actually subtracting c from a .

This is also undefined behavior, since pointer subtraction is only determined if the pointers point to the same array, see section 6.5.6/9 of the C11 draft standard :

[...] When two pointers are subtracted, both must point to elements of the same array object or one after the last element of the array object; [...]

Section 6.5.6/8 is also important:

[...] If both pointer operands and the result point to elements of the same array object or one after the last element of the array object, the evaluation should not lead to overflow; otherwise, the behavior is undefined. [...]

Answer 3

Firstly, in print:

 printf("\nThe address of ab is: %ld\nvalue of a is %ld\nValue of b is %ld\nsize of pointer %ld ", (&a-&c),a,b,sizeof(&a)); 

What you're going through is (&a-&c) , not (&a-&b) . By going through &a-&b , you really get the output:

  The address of ab is: 1 

Why? Probably, the compiler apparently puts a , b , c in sequential memory and looks like it's an array, and in pointer arithmetic, subtraction returns the number of elements, not bytes.

Please note that this is undefined behavior , since pointer arithmetic is only valid when they are actually in the same array, which is not in your example.

Answer 4

I had a mental break and I forgot that the addresses are in hexadecimal and 0x7fff5fbff880 - 0x7fff5fbff878 = 8 (bytes)

Answer 5

The compiler cannot place variables next to each other, possibly because the block does not have 8 free bytes next to it. Another reason may be that there is a significant increase in speed for bytes as a multiple of 64.