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]

<te********@gmail.com> schrieb im Newsbeitrag
news:11*********************@g10g2000cwb.googlegro ups.com...

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]

In article <11*********************@g10g2000cwb.googlegroups. com>,
<te********@gmail.com> wrote:

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.
--
Programming is what happens while you're busy making other plans.

[Walter Roberson]

In article <44***********************@newsread4.arcor-online.net>,
Heinz Ozwirk <ho**********@arcor.de> wrote:

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 is vanity. -- Ecclesiastes

[Keith Thompson]

te********@gmail.com writes:

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Joe Wright]

te********@gmail.com wrote:

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.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Erik Wikström]

On 2006-05-29 23:21, Walter Roberson wrote:

In article <44***********************@newsread4.arcor-online.net>,
Heinz Ozwirk <ho**********@arcor.de> wrote:

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
--
"I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure
out how to use my telephone" -- Bjarne Stroustrup

[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]

ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote:

In article <44***********************@newsread4.arcor-online.net>,
Heinz Ozwirk <ho**********@arcor.de> wrote:

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