SE250:lab-2:mspe044
I had a few initial problems getting emacs to do what I wanted... however eventually got it under control with the help from someone else in the lab.
1) I found the pointer *ip to be 4 bites in size
2) The difference between x and y to be 1 bite (4 bits) 0x22ccbc + 4 = 0x22ccc0
When using (long)&x - (long)&y as apposed to (long)(&x - &y)) the difference was 8 bits, im not sure why this is, in truth it makes no sense to me but im sure we will find out in the lecture
With arr[0] the difference between x and y was 7 With arr[1] the difference between x and y was 2 With arr[2] the difference between x and y was 7 With arr[3] the difference between x and y was 2 With arr[4] the difference between x and y was 2 With arr[5] the difference between x and y was 7 With arr[6] the difference between x and y was 7 With arr[7] the difference between x and y was 7 With arr[8] the difference between x and y was 3 With arr[9] the difference between x and y was 7
In conclusion... memory locations are both dependant on what is being stored and its size (no brainer) and how insane the computer is feeling at the time. This computer is clearly one bear short of a 6 pack...
4) As I pridicted this caused the array to have no effect on X and Y (most proberbly due to the fact that they were declared before the array so it did not push them apart... I still maintain the comp is mad though...?
5) I 'considered' the code:
int *p1, *p2;
{ int q; p1 = &q; }
{ int r; p2 = &r; }
there was a one bite difference in the memory locations of q and r, I found this using the code:
printf("q = %d, r = %d, diff = %ld\n", &p1, &p2, (long) (&p1 - &p2));
placed after the initial 3 lines given, however as in part one I found a pointer to be 4 bites in size, this can't be true (to my understanding) as there would have to be at least a 4 bite gap (as the first pointer is 4 bites long... something interesting to look into however
6) I ran the function code and recieved this as the result:
sp = 0x22cc90 (456) sp = 0x22cc90 (efg) sp = 0x402000 (tuvwxyz) sp = 0xda01a0 (hijklmn)
What I can gather from this is that the second function wiped over the memory of the first function, as it is in the same memory location... the 3rd and 4th functions however created new memory locations so preserved the origional data.
As to interperating the output, for some reason (I have no idea what) the first two functions wiped all but 3 characters of the data... the last two (which also preserved memory) kept ALL of there data when printed to the screen... I doubt verry much that this is a coinsidance but I dont know what the link is.
As a point of interest, adding the seamingly random code: strcpy( sp, "XXXXXXX" ); caused this outcome... printf( "sp X'd = %p(%s)\n", sp, sp );
sp = 0x22cc90(456) sp X'd = 0x22cc90(-0@) sp = 0x22cc90(efg) sp X'd = 0x22cc90(-0@) sp = 0x402000(tuvwxyz) sp X'd = 0x402000(XXXXXXX) sp = 0xda01a0 (hijklmn) sp X'd = 0xda01a0(XXXXXXX)
The added code follows a similer pattern to the origional 4 lines, the first two functions using the same memory location, the 2nd two functions using new memory locations, ironicaly the actaul imformation heled (7*X) was not preserved even to the print statement in the first two (just as it wipes over all memory already in that location it seamingly wiped over memory used AFTER the function call... I dont know how that is (im assuming I have miss interperated this somehow) but it dosnt seem possable...
The result from the added code int he bottom two functions however makes ALOT more sense to me, just doing what I expected the code to do.
As a footnote, what kind of imformation is -0@ anyhow, how the heck that got into sp I will never know?!?!?
After 2 hours working at this Lab im gona call it quits or be late for my next Lecture (will pick it up at some later point)