Motive: Passing struct to functions such as we can change it in any function and retrieve any value in any function.
I picked up this code from: http://cboard.cprogramming.com/c-programming/126381-passing-structure-reference-through-4-functions.html#post942397
I tweaked it a little and here it is:
struct_passing.h
typedef struct thing {
char *x;
}thing_t;
struct_passing.c
#include <stdio.h>
#include "struct_passing.h"
void f4(thing_t *bob) {
bob->x = "changed";
}
void f3(thing_t *bob) {
f4(bob);
printf("inside f3 x: %s\n", bob->x);
}
void f2(thing_t *bob) {
f3(bob);
}
void f1(thing_t *bob) {
f2(bob);
}
int main(void) {
thing_t foo;
foo.x = "same";
printf("Before: %s\n", foo.x);
f1(&foo);
printf("After: %s\n", foo.x);
return 0;
}
It works as expected on **gcc version 4.4.3 on ubuntu
$ gcc -o struct struct_passing.c
$ ./struct
Before: same
inside f3 x: changed
After: changed
But on gcc version 4.2.1 on freebsd, I cannot retrieve the changed value of “bob->x”. I do not get inside f3 x: changed. I get garbage instead.
Why?
Everything looks just fine to me. It’s always instructive to run a small sample program like this in the debugger, to see what’s really happening. If you don’t know gdb, now is a great time to start. I’ve created struct_passing.[ch] from your code, let’s have a look:
Yup, same compiler. Compile for debugging:
And run it:
OK, we probably want to know what’s happening from main() on, so…
We’ll mostly use (s)tep to step into functions, and (n)ext to step over functions we don’t want to see the inside of, like printf(). We may also occasionally (p)rint something.
We haven’t yet executed this line, so if we look at foo, it will probably contain garbage:
Yup, as expected, x points to some garbage string. That’s because foo, and by extension foo.x, got created on the stack in the main() function, and the stack just has whatever random junk was left around before.
So we step into f1() and see that we have correctly passed the address of foo into the function. Notice how the gdb (p)rint function always knows the type of what it’s printing? In this case, seeing the address of the structure isn’t very useful, so:
Oh, good, the structure still looks like it should. Let’s keep going until we change it:
Remember, we haven’t executed line 5 yet, so “bob” should still be the same:
Yup, so let’s execute line 5 and look again:
So “bob” did get changed. Let’s keep going and see if it’s still changed up in main():
So we got what we expected. At this point, we’re about to return from main(), it’s best to just let the debugger continue so you don’t half to walk through the tail end of the C runtime startup code:
Let’s exit the debugger and run it normally to make sure we get the same output. It would be really weird if we didn’t…
Oh, good, the stars are still shining. I’m not sure what happened in your case, let’s try compiling as you did and run it:
So now, let’s improve your bug report. Give us the output of ‘uname -a’, ‘gcc -v’, and ‘ld -v’ so we can find out exactly what system you’re using. Also read the ‘Joel on Software’ article(s) about how to write a bug report. 🙂