ansaurus

Question

Answer 1

A:

0x12345678 # Arbitrary
0x1234567C
0x0000032A # Arbitrary
0x0000032E

Assuming 32 bit integers and pointers. Watch me be incredibly wrong!

EDIT: (Spoilers)

Okay, so this is the result:

0x0022FF60
0x0022FF64
0x0022FF60
0x0022FF70

I was right with the first one, but the second one is a pointer to four integers, so incrementing it increments the pointer by four times the value, in this case, 16 bytes, right?

Bernard 2008-10-24 02:35:08

You are wrong! You are now allowed to run the program and see what happens (you still have to explain it.)

Edward Z. Yang 2008-10-24 02:36:21

Well, not have to; just should. :-)

Edward Z. Yang 2008-10-24 02:36:53

Charlie 2008-10-24 02:59:35

Answer 2

+14 A:

wnoise 2008-10-24 02:40:38

Pointer to int vs pointer to array of 4 integers.

wnoise 2008-10-24 02:41:08

Excellent question, excellent answer. So cool, I still don't get it, so now I'm going back to my cave and think about it for a bit. +1 insightful to wnoise :)

Tom 2008-10-24 07:22:54

Answer 3

A:

Isn't the answer dependent on the direction of stack growth, this hasn't been specified?

2008-10-24 02:41:15

No, because increasing array indexes refer to increasing addresses, no matter which way the stack grows.

Greg Hewgill 2008-10-24 02:59:25

No - as Greg said...

Jonathan Leffler 2008-10-24 03:03:04

Answer 4

A:

Assume that sp is 0x000010000

sizeof(int) is 4

sizeof(int *) is 8

Output will be:

0x000010000
0x000010004
0x000010000
0x000010008

& operator applied to an array does nothing, it's a no-op, since the array is already a pointer.

Moishe 2008-10-24 02:44:53

An array is not a pointer. However, when you reference the array as shown, it becomes a pointer.

Jonathan Leffler 2008-10-24 02:58:44

Also, as the other answers show, the fourth value is 16 bytes 0x10 more than the first.

Jonathan Leffler 2008-10-24 02:59:31

Moishe 2008-10-24 03:05:39

Answer 5

A:

Is the last one supposed to be address of array + 1 byte?

0x12345678
0x1234567C
0x12345678
0x12345679

UPDATE

Based on Bernard's advice, it would then be address + extra 4 bytes address

0x12345678
0x1234567C
0x12345678
0x1234567C

Which is supposed to be wrong answer. I guess not touching C for nearly 15 yrs has its disadvantages :-p

UPDATE2

End lesson is address + extra 16 bytes (according to size of array 4 ints)

0x12345678
0x1234567C
0x12345678
0x12345688

icelava 2008-10-24 02:45:07

Pointer arithmetic doesn't work like straight arithmetic. Any addition is converted into the pointer size first.

Bernard 2008-10-24 02:46:34

Pointer size, so that would be 32bit address = 4 bytes.

icelava 2008-10-24 02:55:20

Jonathan Leffler 2008-10-24 03:00:54

I did consider that, but was not able to verify whether the compiler would indeed take into consideration the array size or not. Is there some documentationo that explains this?

icelava 2008-10-24 03:06:09

"Any addition is converted into the pointer size first" -- I know you meant "size of the pointed-to object" but some of the other posters here don't know you meant that. "Is there some documentationo" -- C language definition 38 years ago, maybe some textbooks since then too.

Windows programmer 2008-10-24 03:10:36

Richard T 2008-10-24 03:19:20

Heh i was asking for some Internet material that discusses this, all that I came across only mentioned addressing between elements in an array, not the whole array itself. But at this stage it is pretty much confirmed an array's size is statically tied to its pointer arithmetic. Thanks.

icelava 2008-10-24 03:44:19

Yes, I did mean size of pointed to object. Sorry for the confusion. :(

Bernard 2008-10-24 04:10:31

Answer 6

+2 A:

wow... it's been a loooong time since the good ol days ...

but... still.

x and &x are basically the same thing here are they not, arrays in C are just syntactic sugar over pointer arithmetic, so my guess would be that basically twice the same pair of lines to be the output of the program above... unless the adress of an adress yields yet another address...

ho... the pain.. my brain hurts... need more beer

weeeel will you look at that, they are both addresses but the pointer arithmetic will be affected differently by the & operator... typing the pointer differently

x being the address of the first element (typed int)
&x being the address of the array of int (typed int[4])

nice, thanks

Newtopian 2008-10-24 02:48:23

Yeah, if I saw that second piece of work in real code, I would be quite confused. But it does work differently, at least on this machine, so I suppose I should do a little boning up on the stuff.

Bernard 2008-10-24 02:52:07

Brian R. Bondy 2008-10-24 03:02:10

I wonder who upvoted this answer.

Windows programmer 2008-10-24 03:05:05

somebody who already had more beer ;-D

icelava 2008-10-24 03:08:32

darn you people are fast... yes Brian, I was editing while you answered ;-).

Newtopian 2008-10-24 03:10:51

Answer 7

+58 A:

The output is undefined behavior because %p requires that the pointer be cast to void * since other pointer types might not have the same size and representation as void *. Assuming that part of the program is corrected, the output would be implementation defined. The output would be an implementation defined representation of the following values, assuming n = the pointer value of the address of the first element of the array:

n
n + sizeof(int)
n 
n + 4 * sizeof(int)

The reason for the first 3 lines should be obvious. The reason for the last line is because &x is of type int(*)[4] and not int *.

Chris Young 2008-10-24 03:06:08

I noticed the %p and said to myself, "Gee, I don't remember using _that_ one in, oh... -damn- too many years to remember!"

Richard T 2008-10-24 03:22:53

it's not much use except for a poor man's debugging. One other rather esoteric use is to printf %p out pointer values to a file then scanf them back with %p. The standard guarantees the resulting pointer be equal to the one written out if it's the same program.

Chris Young 2008-10-24 03:26:06

The part on undefined behavior is wrong. All pointers except function pointers and pointers to member functions can be casted to/from `void *` according to the standard. Things such as DOS far pointers may be exceptions, but they're not included in the standard.Everything else is correct, though.

Paolo Bonzini 2010-09-27 14:14:56

@Paolo: Certainly the can be cast to and from `void *`, but where are they? `printf()` is a variadic function, meaning that pointer arguments are passed as is, and are not cast. Therefore, passing in an `int *` and using it as a `void *` means that an uncast `int *` is used as a `void *`, which is not guaranteed to work. A function explicitly taking a `void *` could take any data pointer, but that's not what `printf` does.

David Thornley 2010-09-27 16:54:58

@David: You're right: "If there is no actual next argument, or if type is not compatible with the type of the actual next argument (as promoted according to the default argument promotions), the behavior is undefined, except for the following cases: [...] one type is pointer to void and the other is a pointer to a character type." I wonder if there is an actual machine that prompted the committee to make the rule this strict, because I have a hard time imagining a `void *` incompatible with another (non-function) pointer.

Paolo Bonzini 2010-10-15 15:55:38

@Paolo: There have been some weird machines. The CDC 6600 had 60-bit words, so it would have had to have 10-bit `char` if there was a C compiler for it, and the `char *` and hence the `void *` would have needed an offset in the word. That's the only computer I personally have ever worked on enough to know addressing where you couldn't designate a byte address with one binary number (although the machine language didn't necessarily use that number, the IBM 360 having sixteen-bit pointers, first four for register used as base, next twelve for offset).

David Thornley 2010-10-15 16:17:48

Answer 8

+105 A:

Edward Z. Yang 2008-10-24 03:12:50

Wow, very interesting. I've been using pointers for years and never knew the difference between a pointer to an array and a pointer to the first element of the array.Thanks for posting this question (and answer)! You learn something new everyday. :)

Bob Somers 2008-10-24 03:50:48

Question about #4, assuming an int is 32 bits (4 bytes), why is the address 10 more and not 16?Oooooohhh, writing it out made me realize I'd forgotten it was Hex... ha!

swilliams 2008-10-24 20:49:50

Upvoting you if only for using readable addresses. I wonder why everyone went for 0x12345678 as opposed to, say, 0. Or 5. (OK, they're unlikely, but still?)

aib 2008-10-28 01:48:30

Answer 9

A:

Like said Bernard the first time:

0x12345678 # Arbitrary

0x1234567C

0x0000032A # Arbitrary

0x0000032E

&x's type is int**, which size is 4 in 32bit... so &x + 1 = 0x0000032E

Nicolas Dorier 2008-10-24 07:07:50

Look more carefully at the other answers, and try compiling/running the program yourself.

Edward Z. Yang 2008-10-26 00:25:15

Answer 10

+2 A:

Technically, there are two "correct" answers because even on a 32-bit architecture, int is allowed to be 16-bit.

zvrba 2008-10-25 16:21:43

Actually, sizeof(int)==1 is also legitimate, if characters are 16-bits (as with some DSP's).

supercat 2010-10-18 16:08:27

Answer 11

A:

Without compiling the program, what does it output, and why? If you think that a certain output will be arbitrary, say so, invent a value, and then pretend that was the value that was output.

Program wont compile. :)

brooksbp 2010-09-27 16:41:07

ansaurus

tags:

views:

answers:

So you think you know pointers?

related questions