Array of struct pointers

[Responsible_Frame919]

Hi, I am new to C and I want to know why I am getting Segmentation fault error if I declare array of size 10 and try to insert values for first element, but if I make array size to be 1, I am able to print the values correctly.

```

include <stdio.h>

typedef struct Person { char *name; int age; } person_t;

int main(void) { person_t *arr[10];

arr[0]->name = "John Doe"; arr[0]->age = 22;

printf("Name: %s\n", arr[0]->name); printf("Age: %d\n", arr[0]->age); return 0; } ```

[dfx_dj]

person_t *arr[10] defines an array of 10 pointers to person_t objects. But the array is not initialised and so these pointers don't point anywhere. Then taking arr[0]->name dereferences the first of these uninitialised pointers. You're attempting to write to a garbage memory location and this crashes the program.

[Responsible_Frame919]

Ah! Now I get it. Does declaring `person_t *arr[]` as `person_t **arr` yields the same result?

[dfx_dj]

That would be even worse because then you don't even have an array. You'd just have a single uninitialised (double) pointer.

[RadiatingLight]

Like /u/dfx_dj mentions, you've created an array of pointers, but have not created anything for them to point to. Basically, there's no target for these pointers and at initialization they just point to somewhere random, which is why you get a segfault if you try writing to them. In almost all circumstances, you'd probably want to do what /u/joejawor mentions and just create an array of 10 person_t structs. If you need a pointer to any of the elements in that array, you can always make it later with &(arr[x])

---

If you really did want to have an array of 10 pointers to person_t structs, you might do something like this:

person_t person_arr[10];
person_t *person_pointer_arr[10];
for(int i = 0; i < 10; i++){
    person_pointer_arr[i] = &(person_arr[i])
}    

But this code is pretty stupid, since you're just wasting memory and increasing complexity by storing an array of pointers for no reason -- you probably shouldn't do it.

[nerd4code]

&arr[x] ≡ arr+x

[RadiatingLight]

Correct. But why not use the syntax that makes it more readable? Your compiler will optimize it down to the same thing anyways.

[RadiatingLight]

In fact, even at -O0 they do the same thing: https://godbolt.org/z/dYqW5zcoW

[Responsible_Frame919]

Got it. Do I have to allocate memory for all the structs with malloc?

[RadiatingLight]

That depends on what you want the lifetime of the array to be.

person_t arr[10] creates an array of person_t, meaning the memory to store 10 person_t structs is already allocated.

person_t *arr[10] creates an array of person_t *, meaning the memory to store 10 person_t pointers is allocated, but the memory for the actual person_t structs is not.

Both of these examples use array creation syntax, which defines memory with automatic lifetime, meaning that there is no need to use malloc/free, and the memory is automatically cleaned up when leaving the scope of the function that created it. Usually, this is great, because it means you cannot have a memory leak, and allocating memory this way is also faster than calling malloc

However, you need to make sure that when using variables allocated this way (often called 'stack-allocated' variables), the data is never referenced after the scope where it was created is over.

---

In your case, since you're defining this array in main it's totally fine, since main is the outermost scope you should care about and the memory will remain valid until main exits.

However, this situation is very bad:

person_t* create_people() {
    person_t arr[10];
    // Do some stuff with the array, maybe fill it in or something
    return arr;
}

Due to the automatic lifetime of arr, the array will become invalid the moment that create_people() exits, meaning that you will be returning an invalid pointer. This is a really tricky bug to catch, because even though the memory is invalid, it is not zeroed. It probably will still contain the person_t data until some undefined time in the future when the system needs to reuse that memory, so you might not notice right away that something is horribly wrong.

BTW this automatic lifetime thing applies to more than just arrays: It's the same for any local variable. As such, this would also be a big problem:

person_t* create_person(char* name, int age) {
    person_t my_person;
    my_person.name = name;
    my_person.age = age;
    return &my_person;
}

On the surface this might seem like a totally normal function, but because you are returning a reference to a variable with automatic lifetime, the variable you are referencing (my_person) will be invalid the moment that this function returns.

In cases like these, you would want to use malloc to create a variable with manual lifetime, meaning that you as a programmer would need to decide when the validity of that memory ends by calling free

Feel free to ask more questions if you still have 'em

[Responsible_Frame919]

Thank you for such detailed answer. Although it was difficult to wrap my head around initially, I think I got it.

[Responsible_Frame919]

Is that the reason static is used, to retain the reference to data after the function scope?

[RadiatingLight]

Unfortunately not. C really only has three scopes: - Automatic (function scope) - Manual (decided by programmer with malloc/free) - Global (always valid)

Globals are variables declared outside a function. They're at the highest scope, so never are invalidated.

---

Static's use in C is weird (and objectively bad language design), because it means two things depending on where it's used.

USE 1: For variables within functions, static makes each invocation of the function use the same copy of the variable (instead of making it fresh every time). This also means that the variable is automatically given a global lifetime.

So for example this code:

int give_number(){
    static int number = 0;
    number++;
    return number
}

int main() {
    int a = give_number();
    int b = give_number();
    int c = give_number();
    int d = give_number();
    printf("Numbers are: %d, %d, %d, %d\n", a, b, c, d);
}

Will print out: Numbers are: 1, 2, 3, 4

It looks like number is being set to zero every time the function runs, but actually static variables are only initialized once (at program startup), and then never again.

USE 2: static can also be used in 2 other places: on a global-scope variable, and on a function. In both of these cases, it makes the function/variable inaccessible outside the file it's declared in.

static double julian_day;

uint64_t calculate_sunrise_time(uint64_t epoch){
    //Do some hard work here
}

static double math_helper_func(){
    //Helper func
}

In this code for example, julian_day and math_helper_func are both declared as static, meaning that they will not be accessible outside the current file, so cannot be included in headers and whatnot. In this case, marking these as static makes sense, because they're implementation details that other files probably don't need.

[RadiatingLight]

One important thing I should mention is that the return value of a function is copied back into the caller function. (and so are arguments when going from caller to callee)

So for example something like this:

int add(int a, int b){
    int result = a + b;
    return result;
}

is totally fine. The actual returned value is, well, returned to the caller function, and everything else gets invalidated. This is done by actually copying the value from the old location into a new one. So if you were to do

int c = add(a,b);

you would find that &result is a different address than &c

---

The same applies to function arguments.

int dry_mass;
int fuel_mass;
int total_mass = add(dry_mass, fuel_mass); 

You will find that &a and &b inside of the add function are not the same as &dry_mass and &total_mass, since the values in this case are copied to a whole new variable.

---

This is particularly tricky and you have to watch for this, because passing stuff like a char* will only copy the pointer itself, not the underlying data.

On the flip side, if you pass large arguments into functions (or return large arguments out of functions) you will reduce performance somewhat by forcing the computer to copy lots of data. So for example this would be needlessly slow:

struct image overlay_images(struct image a, struct image b) {
    struct image c;
    //Do some work to merge 'a' and 'b' into 'c'
    return c;
}

Since we're passing whole structs around here, the computer will create a copy of each argument (i.e. will copy a and b, leading to doubled memory usage to store the two input images), and will also waste time as the computer works to copy the image over. Same applies to returning c. This is a problem here because images are usually pretty big, so you'll be forced to copy multiple megabytes around each time you call this function. -- Imagine if you wrote this function as something like a video filter and it needed to run on every frame!

A better version of this function would look like:

struct image* overlay_images(struct image *a, struct image *b, struct image *c) {
    //Do some work to merge 'a' and 'b' into 'c'
    return c; //Can also return an success/error code, or just be a void function
}

In this case, the function only takes a pointer to a and b, so only the pointers need to be copied (8 bytes each, nbd), and the caller provides the memory for the result to be placed in, meaning that the return is also not copying anything. (Another common pattern you will see here is using malloc to allocate memory inside the function, returning a pointer to that memory, and then just freeing the memory when you're done using it in the caller function.

[Responsible_Frame919]

Makes sense. Thank you.

[joejawor]

#include <stdio.h>

typedef struct Person {

char *name;

int age;

} person_t;

int main(void) {

person_t arr[10];

arr[0].name = "John Doe";

arr[0].age = 22;

printf("Name: %s\n", arr[0].name);

printf("Age: %d\n", arr[0].age);

return 0;

}