increment pointer

[temper3243]

Hi,
I work on a little endian machine.
i have an array int a[]={2,3,4};
i have a pointer int *p;
p=a;
now when i printf(" %x",p);
i got 0xff43n (where n is some value)
now p++
i get 0xff43n+4 (where n+4 is the 4 bytes).
I work on 32 bit machine.

Now my question is that if i do p++ , will it be 0xff43n+4 on little
endian and 0xff43n -4 on big endian.

I think no. It should be the same on the both i mean it increments the
base address by size of work. Am i correct or wrong.

Regards
Nik

 

[Heinz Ozwirk]

Hi,
I work on a little endian machine.
i have an array int a[]={2,3,4};
i have a pointer int *p;
p=a;
now when i printf(" %x",p);
i got 0xff43n (where n is some value)
now p++
i get 0xff43n+4 (where n+4 is the 4 bytes).
I work on 32 bit machine.

Now my question is that if i do p++ , will it be 0xff43n+4 on little
endian and 0xff43n -4 on big endian.

I think no. It should be the same on the both i mean it increments the
base address by size of work. Am i correct or wrong.

On most machines I would expect (int) p to be less than (int)(p + 1), at
least if int is large enough to hold a pointer. But I don't remember that
the standard does require it. Of cause p < (p + 1) or (p+1) - p == 1 should
always be true, but that does not really imply that this should also be true
if you interpret the bit patterns of a pointer as integers. But that
shouldn't really matter. If your program relies on such lowest level
implementation details, you must be doing something really special -- or
wrong.

Regards
Heinz

 

[Walter Roberson]

I work on a little endian machine.
i have an array int a[]={2,3,4};
i have a pointer int *p;
p=a;
now when i printf(" %x",p);
i got 0xff43n (where n is some value)
now p++
i get 0xff43n+4 (where n+4 is the 4 bytes).
I work on 32 bit machine.

Now my question is that if i do p++ , will it be 0xff43n+4 on little
endian and 0xff43n -4 on big endian.

No, but for a completely different reason. %x is not the proper
format to use to print out a pointer, so when you move to a
different machine, you might get any of a variety of results.

 

[Walter Roberson]

On most machines I would expect (int) p to be less than (int)(p + 1), at
least if int is large enough to hold a pointer. But I don't remember that
the standard does require it.

I thought I'd posted a proof of this recently, but I cannot find
the appropriate posting now.

- C requires that addresses within structures are increasing
- one could union an array[10] together with a structure that
was two array[5]
- the second array within the struct must an increased address
relative to the first, due to the first point
- the address of the union would be common base -- which would
be the address of the structure and the address of the array[10]
- thus the address of the array[10] must be the address of the
first array[5] of the struct
- I cannot think of any logical way that after that the address of
the array[10] at index 5 would not be the same as the address
of index 0 of the second array[5]
- So since that second array[5] has an increased address relative
to the first, then the address of the array[10] at index 5 must
be increased in memory relative to that array at index 0, so
arrays must increase in memory

 

[Keith Thompson]

Hi,
I work on a little endian machine.
i have an array int a[]={2,3,4};
i have a pointer int *p;
p=a;
now when i printf(" %x",p);

[...]

You've just invoked undefined behavior.

To print a pointer value, use %p:

printf(" %p", (void*)p);

Incidentally, cross-posting to comp.lang.c and comp.lang.c++ is rarely
a good idea. In C++, something involving "cout << ..." might be a
preferred solution. If you want to discuss that in more detail,
please drop comp.lang.c.

 

[Joe Wright]

Hi,
I work on a little endian machine.
i have an array int a[]={2,3,4};
i have a pointer int *p;
p=a;
now when i printf(" %x",p);
i got 0xff43n (where n is some value)
now p++
i get 0xff43n+4 (where n+4 is the 4 bytes).
I work on 32 bit machine.

Now my question is that if i do p++ , will it be 0xff43n+4 on little
endian and 0xff43n -4 on big endian.

I think no. It should be the same on the both i mean it increments the
base address by size of work. Am i correct or wrong.

Regards
Nik

Endianess has nothing to do with your observations. On your machine..

(sizeof (int) == 4) is true.

Expressing a yields a value of type (int *) which is perfect for..

int *p = a;

The value of p points to the first int in the array such that *p == 2.
If you would then increment p (++p) then *p == 3 will be true.

Endianess has nothing to do with it.

 

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

On most machines I would expect (int) p to be less than (int)(p + 1), at
least if int is large enough to hold a pointer. But I don't remember that
the standard does require it.

I thought I'd posted a proof of this recently, but I cannot find
the appropriate posting now.

- C requires that addresses within structures are increasing
- one could union an array[10] together with a structure that
was two array[5]
- the second array within the struct must an increased address
relative to the first, due to the first point
- the address of the union would be common base -- which would
be the address of the structure and the address of the array[10]
- thus the address of the array[10] must be the address of the
first array[5] of the struct
- I cannot think of any logical way that after that the address of
the array[10] at index 5 would not be the same as the address
of index 0 of the second array[5]

I'm not 100% sure but I believe that the compiler is allowed to add
padding between the two array[5]. An example would be if you used arrays
of char (one byte per element) and the architecture aligns all data-
structures on 4-byte boundaries, which would mean that there would be 3
bytes padding between the arrays.

This of course does not have any direct bearing on your reasoning but
illustrates the danger of doing cleaver things with unions.

- So since that second array[5] has an increased address relative
to the first, then the address of the array[10] at index 5 must
be increased in memory relative to that array at index 0, so
arrays must increase in memory

Erik Wikström

 

[Tomás]

Erik Wikström posted:

I'm not 100% sure but I believe that the compiler is allowed to add
padding between the two array[5]. An example would be if you used
arrays of char (one byte per element) and the architecture aligns all
data- structures on 4-byte boundaries, which would mean that there
would be 3 bytes padding between the arrays.

This of course does not have any direct bearing on your reasoning but
illustrates the danger of doing cleaver things with unions.

- So since that second array[5] has an increased address relative
to the first, then the address of the array[10] at index 5 must
be increased in memory relative to that array at index 0, so
arrays must increase in memory

Erik Wikström

Good catch. There's a recent discussion about this on comp.std.c++.

union Monkey {

array1[10];

struct {
array2[5];
array3[5];
};

};



int main()
{
Monkey obj;

assert( (obj.array1 + 5) == (obj.array3) );
}


This is well within its rights to cause an assertion failure.


-Tomás

 

[Richard Bos]

On most machines I would expect (int) p to be less than (int)(p + 1), at
least if int is large enough to hold a pointer. But I don't remember that
the standard does require it.

I thought I'd posted a proof of this recently, but I cannot find
the appropriate posting now.

- C requires that addresses within structures are increasing
- one could union an array[10] together with a structure that
was two array[5]
- the second array within the struct must an increased address
relative to the first, due to the first point
- the address of the union would be common base -- which would
be the address of the structure and the address of the array[10]
- thus the address of the array[10] must be the address of the
first array[5] of the struct
- I cannot think of any logical way that after that the address of
the array[10] at index 5 would not be the same as the address
of index 0 of the second array[5]
- So since that second array[5] has an increased address relative
to the first, then the address of the array[10] at index 5 must
be increased in memory relative to that array at index 0, so
arrays must increase in memory

All of this is true, but it merely demonstrates that p must compare
smaller than p+1, not that (int)p must compare smaller than (int)p+1.

Richard