Declaration and Allocation

Question

I have some doubts about C allocations.

#include <stdlib.h>

typedef struct MyStruct {
    char CharsInMyStruct[50];
} MyStruct;

int main(void) {

    struct MyStruct * s;

    s = malloc(100 * sizeof *s);
}

I was told that the allocation is "smart", because the space is not "really" (physically) allocated until I use the memory. Is the memory physically allocated once I use the first element of MyStruct or it's allocated when I use each element?

I thought that if I need to dynamically read a file and copy each row in a dynamic struct, I could just allocate for 100 elements, then realloc for the correct dimension after reading the file, so I don't have to read two times to previously know how much to allocate or to realloc for each row. Is that possible / allowed? Is it a good solution?

Edit: sorry, I was too concerned about theory and I forgot to add a decent code. Maybe the question is not clear enough, but I don't need to know how to code what I'm thinking about; I just need to know how the memory is allocated.

Answer 1

In principle, calling malloc() causes the requested memory to be allocated immediately. If it's unable to do so, the malloc() call returns a null pointer to let the caller know.

In practice, though some systems (including Linux) use "lazy allocation". The malloc() call immediately allocates a range of memory addresses, but doesn't necessarily allocate the actual memory pages right away. When your program later accesses the "allocated" memory, physical memory is allocated by the kernel. The idea is to avoid allocating memory that might never be used, particularly when forking processes (a child process inherits a copy of its parent's memory, but typically exec()s another executable before using it.)

One big drawback of this approach is that if the memory isn't available when you try to use it, there's no clean way to report the failure. When the system is short on memory, the "OOM killer" may start killing processes -- not necessarily the one that performed the allocation.

It's been argued that this behavior causes C implementations on Linux to be non-conforming.

I'm less familiar with non-Linux systems.

For most practical purposes, though, as long as you're not allocating huge amounts of memory, you can probably ignore all this. You should always check whether malloc() reported failure by returning a null pointer, and take some action (even if you just terminate your program). If you do a large malloc in an infinite loop, bad things are likely to happen. But when resources are in short supply for whatever reason, programs are likely to start crashing anyway. Your best defense is to design your program so it doesn't leave things in an inconsistent state if it terminates unexpectedly.

Answer 2

As comment said:

struct myStruct * structLink;
structLink = malloc (sizeof(struct myStruct));

Also when finished:

free(structLink);

To deallocate.

Answer 3

As others have said, logically malloc() allocates the space and it is available for use immediately. As Keith Thompson noted in his answer, Linux takes a lazy approach to memory allocation, so you can (if you're unlucky) allocate space, check that it was allocated, and yet still crash later because the memory wasn't available after all.

1. Yes, it is legitimate to allocate 100 entries, read from a file to populate some of those entries, and then realloc() to shrink the array to the required size if there are fewer than 100 entries after all.

2. You can also allocate an array of entries (say 2 entries to start with), and realloc() the space to add more entries as required. However, to avoid quadratic behaviour (copying the old space to new space), the standard advice is to double the number of entries each time you realloc(). You can always apply the shrinking realloc() after the loop if you're worried about over-allocation. Use a small value to start with so that the realloc() code does get exercised (tested, debugged).

Answer 4

I think you may have your thoughts on memory usage wrong. When you allocate memory, the memory is always there to begin with, malloc just tells the computer to reserve this much space for you. When you use free() after you're done, the pointer that you freed will still be pointing to that address. The only difference is that the program will know it's not your space to use anymore. ( Though C will probably still allow you until you get a segment fault )

As for your second paragraph, the way you do it depends upon implementation. Though really I don't see why you cannot just malloc on the go every time you read in a new file.

Pardon if this isn't what you're looking for.