C arrays and pointers etc. Help!

I have the code

Code:

---

int k = 2;
int a[10];
int b = 0;

for(b=0;b<10;b++)
{
a[b] = 2;
}

printf("Normally with a[k] we get %d\n", a[k]);

int c;

c = *(int *) ((int)&a[0] + k*sizeof(int));

printf("So c = %d\n", c);

---

Where I'm just printing out a value from the array "a". However, I don't get why

Code:

---

c = *(int *) ((int)&a[0] + k*sizeof(int));

---

works exactly the same as a[k].

I've been told

*(int *) = indirect
(int)&a[0] = base address
k*sizeof(int) = offset

I know that the end bit selects which value in the array I want (how many objects away from the start of the array the thing I want is), but I don't get what the other two parts do.

Thanks

Does this help?

& = address of
(int *) = cast to pointer to int
(int) = cast to int
* = dereference (get the value at address)

I think I have that right.

When you add an integer (say, 4) to a pointer, C will not just add 4 bytes to your pointer. Rather, it scales the integer to the size of the pointed-to object, so if you added 4 to a pointer to int, you get the fourth int, not the fourth byte.

This is why the code is casting &a[0] (a pointer) to an int: now when an integer is added, scaling is not done. But casting a pointer to an int is really not a good idea. To achieve what this code is trying to do, you want to cast to a pointer to char. A char is a byte, so no scaling is needed, and the conversion to a char pointer is much less dicey than the conversion to an int. So, with that modification, here's what's going on:

Code:

---

int a[10] = { 0, 1, 2 };
int k = 2;

/* Now I'll break it down into some rather useless
 * C statements for illustrative purposes.
 */

/* This is a pointer to the first element of your array.
 * The pointer has type int *.
 */
&a[0];
/* This expression is also a pointer to the first element,
 * but more properly, to the first byte of the first element.
 * It has type char *.
 */
(char *)&a[0];
/* Now k * sizeof(int) bytes are being added to the char
 * pointer.  The resulting value is a pointer to the "k"th
 * element of the array (since k is 2, this is the 2nd element).
 */
(char *)&a[0] + k * sizeof(int);
/* Great, we have a pointer to the 2nd element.  But our
 * pointer has type char *, which means if we try to
 * dereference it, we'll only get a single byte.  So, convert
 * the pointer to an int *, so a dereference will get the
 * whole int.
 */
(int *)((char *)&a[0] + k * sizeof(int));
/* And finally, the dereference. */
*(int *)((char *)&a[0] + k * sizeof(int));
printf("%d\n", *(int *)((char *)&a[0] + k * sizeof(int)));

---

Pointing a char * at any object (like I've done above) is legal, at least in C99. Converting it back to an int * I'm not so sure about, but an implementation would probably have to go to some extra effort to prevent you from doing it. It's not too useful, of course, since we have the [] operator for array access.

That awesome car!

Cool

So when you have

Code:

---

*(int *)

---

at the beginning of the code what is the (int*) bit doing? Does the * bit at the very biginning just mean "print out the value at the memory location [whatever]"?

Also, what is the difference between

Code:

---

(char *)&a[0];

---

and

Code:

---

(char )&a[0];

---

without the * ?

I'm still learning C, so sorry if my questions seem basic/idiotic.

Thanks!

First question: pretty much. The asterisk (*) is the pointer dereference operator in C. For example:

Code:

---

int i = 5;
int *p;
p = &i;
*p = 4;

---

Here the * operator tells the compiler to look at the value of the variable p and treat that value as an address, and then store the value 4 into that location in memory.

Basically, *p and i refer to the same thing.

The reverse of * is &, which takes the address of a variable. &i is the address in memory where i is located.

Quote:

---

Also, what is the difference between

Code:

---

(char *)&a[0];

---

and

Code:

---

(char )&a[0];

---

without the * ?

---

A world of a difference. The first tries to convert &a[0] (which is an int *) into a char *, that is, a pointer-to-char. The second tries to convert it to an ordinary char; since most memory addresses are outside the range of a char (128 for a max, generally), it will almost certainly cause an overflow.

Perhaps you should read a few tutorials about pointers. Just stick something like "c pointer tutorial" into Google and you'll find something. There are even some on this site. cprogramming.com/tutorial.html

lets say I have an array of int's

Code:

---

int foo[5];
char a;

---

and I want to access the LSB bytes in that array for sme reason, I can get those by

Code:

---

a = *(char*)&foo[1];

---

this takes the address of f[1] and recasts it to a char* then takes the data at that address, which being a char pointer is a char and on a little endian machine will be the LSB of the original int foo[1].

I can then convert that value back in to an int by

Code:

---

foo[1] = (int)a;

---

so now foo[1] is equal to the LSB of the original value it held.

Ok, this is quite stupid.

int foo[5];

foo IS A POINTER!! Test it out, try inserting printf("%d.\n", foo). You'll see that this prints an address, not a value.

There is no need to cast foo since it is a pointer. That is, foo is the same as &foo[0]. Lets look at whats going on in a bit more depth. When the compiler sees this declaration it creates an array of 5 ints on the stack. Foo is assigned the address of the first int. The compiler knows that the ints are side by side in memory so, knowing the first and the size allows it to get the rest of them. So when it gets an index such as foo[1] you can think of it as the compiler changing the pointer to point to the correct thing and then finding that value. So how does it do this? It takes the base (which is foo) and adding the offset (which is index * the size of the array element, in our case an int) and then finding the value at that memory location. So what does that look like in code? It is * (foo + 1 * sizeof(int)). Look familiar? Thats the uncluttered version of what you have above. foo is the base. 1*sizeof(int) is the offset (note that the *sizeof(int) part is only what happens under the hood, in code what would work is *(foo + 1) (see below for more details) the compiler automatically adds the *sizeof(int) and the star at the beginning is a dereference. So lets look at foo[0]. This evaluates to *(foo + 0 * sizeof(int)) which is the same as *foo. Then you did an & which gets the address of the variable so &foo[0] is the same as &*foo which is the same as foo (since the address of a dereference is the variable).

Now, the rest is an error which happens to not have an effect on your system. You took this pointer and casted it to an int. On some systems, the size of an int is 4 bytes and the size of a pointer is 8 bytes. This would cause the compiler to truncate the result. You then took that int and recast it to a pointer and tried to dereference it. This works given that the size of an int is greater than or equal to the size of an pointer (in our case a pointer to an int).

So now, the only reason that cas casted (hehe) the pointer to a char * is because the sizeof a char is 1 byte. The reason this matters is that when you are adding an int to a pointer the int gets scaled by the size of the type of the pointer. So, adding 2 to an int* is really adding 2*sizeof(int) to the pointer. So this means that *(foo + 1) is the same as foo[1] (because the compiler adds the *sizeof(int) bit. The better way to think about it is as actually adding *sizeof(*foo). The compiler would evaluate and find that foo points to an int and then replace *foo with int.

Hope this clears some things up.
chacham15

> Converting it back to an int * I'm not so sure about

char * and void * have the same representation and alignment, so you could just cast to void * and then cast to int *.

I think.

Quote:

---

char * and void * have the same representation and alignment, so you could just cast to void * and then cast to int *.

---

Well, the problem as far as I see it is that the standard doesn't guarantee that a conversion back to the original type will be meaningful if it's been modified. It's not so much a matter of types as it is values.

Realistically, it should be fine. Technically it's probably not legal.

> foo IS A POINTER!!
Bzzt - wrong, no it isn't.
http://c-faq.com/aryptr/index.html
It's true that in many places where you use foo, it decays into "pointer to int", but that doesn't make foo itself "pointer to int". foo (as you've written it) is an "array of 5 int"

Not convinced?

Code:

---

void func ( int *a ) {
  printf( "%ld\n", sizeof(a) );
}
int main ( ) {
  int foo[5];
  int *bar = foo; // now this IS a pointer
  printf( "%ld\n", sizeof(foo) );
  func( foo );
  printf( "%ld\n", sizeof(bar) );
  func( bar );
  return 0;
}

---

Your suggestion that foo is just a pointer would have these producing the same answer.


> c = *(int *) ((int)&a[0] + k*sizeof(int));
If some book is teaching you this, then get another book.
Casting a pointer to an int doesn't work on some machines.
IMO, you're learning a bunch of bad habits, and you've only just started.

As cas says, the only pointer cast which is guaranteed is the round trip T* to void* and back to T*

Quote:

---

Originally Posted by Salem

> foo IS A POINTER!!
Bzzt - wrong, no it isn't.
http://c-faq.com/aryptr/index.html
It's true that in many places where you use foo, it decays into "pointer to int", but that doesn't make foo itself "pointer to int". foo (as you've written it) is an "array of 5 int"

Not convinced?

Code:

---

void func ( int *a ) {
  printf( "%ld\n", sizeof(a) );
}
int main ( ) {
  int foo[5];
  int *bar = foo; // now this IS a pointer
  printf( "%ld\n", sizeof(foo) );
  func( foo );
  printf( "%ld\n", sizeof(bar) );
  func( bar );
  return 0;
}

---

Your suggestion that foo is just a pointer would have these producing the same answer.


> c = *(int *) ((int)&a[0] + k*sizeof(int));
If some book is teaching you this, then get another book.
Casting a pointer to an int doesn't work on some machines.
IMO, you're learning a bunch of bad habits, and you've only just started.

As cas says, the only pointer cast which is guaranteed is the round trip T* to void* and back to T*

---

Bzzt - wrong, no it isn't.

Wow. Just wow. What you are missing is that sizeof is a preprocessor directive. That means that in the function all the preprocessor knows is that the argument is a int* so it will place the size of the pointer there. The same with sizeof(bar). The problem is sizeof(foo). While internally the compiler treats foo as an int* the preprocessor realizes that its an array and returns the size of the array*sizeof(int). A lot of things go on before the compiler has its way or even that that compiler does. For example, creating a 2D array. There is actually no such thing (unless you manually create it with pointers). So, what does the compiler actually do with that? It creates a 1D array and places the next element of the 2d array right after the first. Then when you do a double index, the first index uses sizeof(array)*sizeof(element in array) while the second index uses sizeof(element in array) so you then get a single index into a larger array.

Casting a pointer to an int doesn't work on some machines.
Bzzt - wrong.

Casting a pointer to an int works on all machines. On some machines this will drop some data, but its not a compile error. Plus, I've said this in my previous post.

If you dont believe me about the foo being a pointer i suggest you try and do what I said (or at least explain what is going on, as I have in your situation). In case you forgot, that is do a printf("%x", foo); and see what that gets you.

Salem is right, you are wrong.

1. sizeof() is not a preprocessor directive. It is compiler proper - that's why you can't do something like

Code:

---

#if sizeof(a) == sizeof(b)
// do something here
#else
// do something else
#endif

---

That won't compile, because sizeof is not resolved at pre-processor time.

2. You can CERTAINLY create a 2D, 3D or 4D array:

Code:

---

int oned[10];
int twod[10][10];
int threed[10][10][10];
int fourd[10][10][10][10];

---

3.

Quote:

---

Casting a pointer to an int doesn't work on some machines.
Bzzt - wrong.

---

Yes, of course, you can cast it to an integer - but the result is not particularly meaningful for the purpose of converting it BACK to a pointer. For example if you drop the upper 32 bits of a 64-bit pointer and then convert that back to a 64-bit pointer, it is quite likely no longer a valid pointer, and it will certainly no longer point to the original data [unless the upper bits were all 0 or all 1 - meaning that the pointer was within the first or last 2GB of memory - and many OS's purposely make sure that addresses of 64-bit applications are OUTSIDE of the 2GB at either end to catch applications making that mistake].

--
Mats

> Casting a pointer to an int works on all machines. On some machines this will drop some data
How can that ever be acceptable?

Even on ancient DOS, when you had 16 bit integers and 32 bit far pointers, all that you got was a world of pain.

As for the rest of your wibble on sizeof, go read a book!


> If you dont believe me about the foo being a pointer i suggest you try and do what I said (or at least explain what is going on, as I have in your situation).
Because that's one of the situations in which an array name decays to a pointer.
But just because it does, DOES NOT IMMEDIATELY MAKE the whole thing a pointer.
Did you bother to read the c.l.c FAQ, I bet you didn't.

C performs special additional mathematical changes when a pointer of any type is being added to, in order to make up for the size of each element. C actually distinguishes between arrays and pointers in this regard and will adjust accordingly. This is usually discovered when dealing with multidimensional arrays.

>You can CERTAINLY create a 2D, 3D or 4D array:

Its only in your mind that that array can exist in more than one dimension, the compiler translates any higher dimensions into a single dimensions placed side by side but it cant always do the job. In order to create a true multidimensional array you need ptrs. The key difference is:

int foo[2][2][2][2];
foo[0][0][0][0] = 2;
foo[0][1][0][0] = 3;
int ****bar = foo; //wrong
printf("%d", bar[0][0][0][0]); //this segfaults
int *headptr = foo;
printf("%d", headptr[4]); //this works, why? the index is clearly out of bounds....because its a 1d array! This is the equivaluent of what you would think of as foo[0][1][0][0]. The following is a true multidimensional array.

int **twodimen = malloc(2*sizeof(int*));
twodimen[0] = malloc(2*sizeof(int));
twodimen[1] = malloc(2*sizeof(int));
twodimen[1][1] = 5;
int **test = twodimen;
printf("%d", test[1][1]); //This works!!


> This is usually discovered when dealing with multidimensional arrays.

As i said earlier, theres no such thing. Its simply a compiler hack (i.e. int foo[2][2] is implemented as int foo[4] and foo[1][1] gets translated to foo[3]...see above)

>Because that's one of the situations in which an array name decays to a pointer.

Thats semantics. It is for all intensive purposes a pointer.

>sizeof() is not a preprocessor directive. It is compiler proper - that's why you can't do something like

What I meant was that sizeof behaves like a preprocessor directive in that it isnt a real function. The compiler evaluates the size and then replaces the function call with the real number (i.e. malloc(sizeof(int)) gets translated to whatever target equivalent of the mips: $a0 = 4; jal malloc (for non assembly people: malloc(4)). Hence the uselesness of a function which evaluates the size of its argument (it'll always be the same).

Multidimensional arrays are implemented as arrays of arrays, not as single dimensional arrays, although the layout is the same either way (they must be contiguous). I'm talking about C's type system.

The problem, though, is that you just can't go poking around where you want as far as C is concerned, even if you "know" where things are. At least, when you do start poking around all bets are off.

This is not legal:

Code:

---

int foo[2][2][2][2];
int *headptr = foo;

---

The initialization of headptr is a constraint violation since the types don't match. You could instead do:

Code:

---

int foo[2][2][2][2];
int *headptr = &foo[0][0][0][0];

---

Now the types match. But according to the standard, you can't access beyond headptr[1], even though we all know how the array is laid out. An implementation would probably have to go to extra effort to stop you ... but it's still a violation of the rules.

You could cast in the first example. But a cast is normally a sign of trying to sneak behind C's back and break the rules. Again, while we "know" it will work, it's not legal C, although perhaps a case could be made that this method is acceptable. I doubt it, though.

To reiterate, this is all inside the scope of C's rules. In one sense a multidimensional array is the same as a large single dimensional array, but as far as C is concerned, they are different animals, even if it mandates that they're laid out the same way. I think this is a rather subtle concept, but not a useless one.

Yes, in the first example if you wanted you'd do an explicit cast. This, however, isnt necessary as the compiler will guess at what you mean. This fits in with the entire theme, rules are meant to be broken. You just have to know what you are doing. For example, you can rely on headptr[4] working because you know that the memory is contiguous. Why i chose those words is that a block of 16 bytes can be thought of as 16 blocks of 1 byte is just a matter of interpretation. But the problem with the int foo[20][20] is the fact that you cannot have any other function reference withough going through many pains unless you use my 'illegal' assumption that the blocks are laid out continuously. The only "proper" way would be to pass a pointer to the head of every 1d array (sooooooooooooo much less efficient and unnecessaary!). The mere fact that its so annoying to do otherwise is reason enough to break the rules. (Another famous example of this is breaking the "dont use goto's rule" (which as legal, but more of a rule of thumb) in order to get out of nested loops. You just need to know what you're doing. (I saw someone goto into a different function...ooh that was bad)

P.S. truely multidimenional arrays such as the one i presented earlier will not be arranged in the same way as this array.

> int ****bar = foo; //wrong
Well that's because you got the type wrong!

int (*bar)[2][2][2] = foo;
would be much better.

Do you have any problems passing multiple dimension arrays to functions?
It seems from what you've been saying that you would.


> >Because that's one of the situations in which an array name decays to a pointer.
> Thats semantics. It is for all intensive purposes a pointer.
It's not a pointer when you use it with sizeof - it's more than semantics!

> What I meant was that sizeof behaves like a preprocessor directive in that it isnt a real function.
It's called an operator, which is neither a pre-processor directive, nor a function call.
It's a unique operator in that it uses a sequence of characters (sizeof) rather than symbols (+,- etc).
Check your operator precedence table, it's listed there.

> printf("%d", headptr[4]); //this works, why? the index is clearly out of bounds....because its a 1d array!
"Works" maybe, but of dubious legality.
http://c-faq.com/aryptr/ary2dfunc2.html
"Flattening the array" is a known technique.
But it wouldn't work with your malloc'ed array which followed.

Incidentally, you can malloc a 2D array in one step.
int (*twod)[4] = malloc ( 4 * sizeof *twod );
you now have twod[0][0] through to twod[3][3]
AND it satisfies your flattened array techniques.

But I'm sure that use of sizeof will flummox you even more than it does already ;)

Quote:

---

Yes, in the first example if you wanted you'd do an explicit cast. This, however, isnt necessary as the compiler will guess at what you mean.

---

A compiler is obligated to do no such thing. What it is obligated to do is issue a diagnostic because a constraint is violated. Apart from that, it needn't actually complete translation.

As for the rest, if you're not worried about breaking the rules of C, we'll just have to agree to disagree on that one.

Quote:

---

Originally Posted by chacham15

This fits in with the entire theme, rules are meant to be broken. You just have to know what you are doing.

---

This is the problem with many people that profess to have advanced knowledge of C.

Quote:

---

Originally Posted by chacham15

>You can CERTAINLY create a 2D, 3D or 4D array:

Its only in your mind that that array can exist in more than one dimension, the compiler translates any higher dimensions into a single dimensions placed side by side but it cant always do the job.

---

Yes, until we invent multi-dimensional memory, the compiler will have to do that - but the fact is that the compiler WILL do that for us, so we don't need to worry about it, and you can pass multidimensional arrays to other functions, and it will still do that [assuming we pass the array dimensions with it - except for the first dimension].

Yes, you can replace any array with a one-dimensional array - and then do the relevant math yourself. But which is easier to read of these two:

Code:

---

b = a[z][y][x]

---

or

Code:

---

b = a[z * dimy * dimx + y * dimx + x];

---

If the compiler does it for you, that's a great help.

--
Mats

> It's not a pointer when you use it with sizeof - it's more than semantics!

sizeof isnt a real function!!!

> It's a unique operator in that it uses a sequence of characters (sizeof) rather than symbols (+,- etc).

there is no assembly code corresponding to the evaluation of this whereas int j = 1 + i does have assembly which corresponds to it.


>But it wouldn't work with your malloc'ed array which followed.
Thats the point, the malloced array is a real multidimensional array unlike the array we pretend is more than 1d

>Incidentally, you can malloc a 2D array in one step.
you can malloc anycontinuous block of memory in one step...but i never said that that was a true 2d array the one i malloc is.

>A compiler is obligated to do no such thing
are you saying that the compiler will error? I've never seen that and if it does, get a different compiler. (note, im talking casts like the one i skipped, not casts which require a conversion)

>you're not worried about breaking the rules of C
given requirements such as performance, sometimes its necessary, wouldnt you say?

>This is the problem with many people that profess to have advanced knowledge of C.
this is a very negative wording. What i mean is if you dont stricly follow rules of the language you'd better know what you're doing. However, you dont need all that advanced knowledge of C to break a few rules here and there.

>If the compiler does it for you, that's a great help.
100% agreed. When the compiler doesnt help you, then you break some rules.

Quote:

---

Originally Posted by chacham15

> It's not a pointer when you use it with sizeof - it's more than semantics!

sizeof isnt a real function!!!

---

Not in the sense that you can call it and see code, no. Because the compiler knows the size of the data in itself, so the result of sizeof() is ALWAYS a constant [a different constant for different "calls" of sizeof, but still one value for any particular instance], so there is no need a runtime version of sizeof().

Quote:

---

> It's a unique operator in that it uses a sequence of characters (sizeof) rather than symbols (+,- etc).

there is no assembly code corresponding to the evaluation of this whereas int j = 1 + i does have assembly which corresponds to it.

---

But the compiler is allowed to replace that with a constant expression if "i" has a known value at compile-time. Since the sizeof() ALWAYS turns into a constant value [or a compiler error], there is no need for an assembler instruction for it.

Quote:

---

>But it wouldn't work with your malloc'ed array which followed.
Thats the point, the malloced array is a real multidimensional array unlike the array we pretend is more than 1d

---

A malloced "2d array" is not a two-dimensional array. It is an array of pointers [first dimension] that point to memory representing the second dimension. It is no more a 2D array than a single block of memory representing an array.

Quote:

---

>you're not worried about breaking the rules of C
given requirements such as performance, sometimes its necessary, wouldnt you say?

---

But you need to:
1. Determine that there is no other better solution.
2. Understand the consequences of this type of choice [e.g. there is a limitation of the portability of the code - which may not be a problem, but if you or someone else plainly assume that because it's C it's portable, then you would probably end up with some code that doesn't work sooner or later].
3. Understand that someone else may need to ALSO understand these consequences, so you'd better document what you have done, why you choose to do so, and how it actually works, and what the consequences would be when the assumptions you made are not longer valid.

--
Mats

Quote:

---

(I saw someone goto into a different function...ooh that was bad)

---

And it would be a compiler error, too. That's why setjmp was invented. (Please don't use it. It's worse than goto.)

> As cas says, the only pointer cast which is guaranteed is the round trip T* to void* and back to T*

C99 (6.3.2.3.7) guarantees round-trip if a converted pointer is correctly aligned for the pointed-to type.

>And it would be a compiler error, too. That's why setjmp was invented. (Please don't use it. It's worse than goto.)

haha, cool. I dont think his compiler errored, perhaps he did the goto in assembly.

>Not in the sense that you can call it and see code, no
Im glad you agree


>if "i" has a known value at compile-time
lol, its a variable...say it with me: var-i-a-ble.

And as far as the numbers I agree with 2 and 3. My reasoning for 1 is that a different way to do may be possible but require lots of extra effort and time which you dont have.

Oh, also, some technically illegal code is very portable (the multidimensional array thing for example)

Quote:

---

>if "i" has a known value at compile-time
lol, its a variable...say it with me: var-i-a-ble.

---

Since you seem to know assembly, why not try examining the assembly that your compiler produces for this? (Be sure to enable optimisations.)

Code:

---

#include <stdio.h>
#include <stddef.h>

int main() {
    const size_t x = sizeof(int);
    printf("&#37;ld\n", (unsigned long)x);
    return 0;
}

---

I haven't tried it, but I'd guess that sizeof(int) (probably 4) is pushed onto the stack rather than x when printf is called.

Quote:

---

>A compiler is obligated to do no such thing
are you saying that the compiler will error? I've never seen that and if it does, get a different compiler. (note, im talking casts like the one i skipped, not casts which require a conversion)

---

The standard makes no distinction between warnings and errors. What I am saying is that a diagnostic is required. Further, the compiler is not required to actually finish translating. That's not indicative of a bad compiler, either. Write code that conforms to the standard.

Quote:

---

>you're not worried about breaking the rules of C
given requirements such as performance, sometimes its necessary, wouldnt you say?

---

It depends on what you mean, but generally, no. Obviously you wind up using a lot more than standard C (Such as POSIX + X11, for example), but I don't violate language rules in some quixotic quest for performance. Most times somebody is talking about performance he hasn't actually profiled the code in question.

I'm not arguing against doing platform-specific things from time to time. It's clearly a necessity. But there's a difference between needing to know the endianness of a system, for example, versus going beyond the end of an array. With experience, you learn what is acceptable and what is not.

A good rule of thumb: If it can be done in standard-conforming code, do it in standard-conforming code.

Zug zug.

By the way, in regards to:

Quote:

---

Originally Posted by chacham15

Thats semantics. It is for all intensive purposes a pointer.

---

The correct phrase is, "For all intents and purposes." For some reason, it really irks me when people screw this up.