Example #2: Deleting an element from the end of an array
int arr[] = { 9,4,6,1, 7 };
int cap=5, cnt = 5;
arr: [9][4][6][1][7]
^
|
end of array
--cnt; /* delete/deallocate/reclaim last elem in the array */
arr: [9][4][6][1][7]
^
|
end of array
Note how this simple operation of decrementing the cnt effects a deletion of the last element and the space occupied by the 7 has been reclaimed. Overwriting it with some special value is unnecessary. The cnt marks the end of the array. A critical property of a deallocation/recycling scheme is that (when possible) it does not require time proportional to the size of the object being deallocated.
Chapter 4.2 The heap & dynamic variables
Before we demonstrate how to allocate dynamic memory it will be helpful to compare and contrast the advantages of dynamic over automatic allocation. Once you understand the advantages of dynamic memory we will show you how to use it.
| Automatic | Dynamic |
|---|---|
| dimension of array must be decided at compile time | dimension decision can be deferred till runtime at the moment of need |
| array's memory is not reclaimed until its name goes out of scope | array is immune to scope and programmer controls exactly when array's memory is destroyed/reclaimed |
| array (or variable) has a name that stays with it for life | array (or variable) has no name - so you better have saved its address into a pointer variable when you alloc'ed it |
| array is stored in the stack | array is stored in separate region called the heap |
The first point above about dynamic memory is probably the most important advantage over automatic. You do not have to make guesses when you are writing your program as to how big of an array you will need. Dynamic memory allows you to defer that allocation decision until the program is running. Thus for example, you can query the file system as to how big a file is so you know how much array you need to read in all the values from that file. The second point is also a tremendous win. Dynamic memory does not get reclaimed until you explicitly cause it to be. This means you can recycle that memory as soon as you are done with the array instead of having to wait until some scoping block is exited. You completely control memory usage and can maximize efficiency.
One of the highlights of this chapter is the combining of these two advantages to solve the buffer overflow problem with dynamic allocation.
Dynamic memory in C is allocated from the heap at runtime using malloc() or one of its sibling functions: calloc() and realloc(). Dynamic memory is deallocated or recycled to the heap by the free() function. Let's see what the man pages have to say about malloc() and its siblings.
bash-2.05b$ man malloc
MALLOC(3) Linux Programmer's Manual MALLOC(3)
NAME
calloc, malloc, free, realloc - Allocate and free dynamic memory
SYNOPSIS
#include <stdlib.h>
void *calloc(size_t nmemb, size_t size);
void *malloc(size_t size);
void free(void *ptr);
void *realloc(void *ptr, size_t size);
DESCRIPTION
calloc() allocates memory for an array of nmemb elements of size bytes
each and returns a pointer to the allocated memory. The memory is set
to zero.
malloc() allocates size bytes and returns a pointer to the allocated
memory. The memory is not cleared.
free() frees the memory space pointed to by ptr, which must have been
returned by a previous call to malloc(), calloc() or realloc(). Other
wise, or if free(ptr) has already been called before, undefined
behaviour occurs. If ptr is NULL, no operation is performed.
realloc() changes the size of the memory block pointed to by ptr to
size bytes. The contents will be unchanged to the minimum of the old
and new sizes; newly allocated memory will be uninitialized. If ptr is
NULL, the call is equivalent to malloc(size); if size is equal to zero,
the call is equivalent to free(ptr). Unless ptr is NULL, it must have
been returned by an earlier call to malloc(), calloc() or realloc().
RETURN VALUE
For calloc() and malloc(), the value returned is a pointer to the allo-
cated memory, which is suitably aligned for any kind of variable, or
NULL if the request fails.
free() returns no value.
|
Chapter 4.3 Dynamic arrays & strings
GOOD PRACTICE: Once you malloc into a pointer - do not modify that pointer var. If you need to traverse or iterate through that array you should declare and use other pointer vars. Keep the original pointer pristine.
RULE OF THUMB: For every call to malloc there must be an assignment into a pointer variable to avoid leaks and there must eventually be a call to free() on that pristine pointer value.
malloc() takes only one arg value - an unsigned long that represents the number of bytes you want allocated. Notice however that when we malloc an array, we pass an expression to malloc that is the number of elements requested times the size in bytes of each element. The product of the two factors is the total bytes requested. This is the common practice as it is self documenting and clearer to programmer and reader. The memory elements allocated by malloc() are guaranteed contiguous just like automatic arrays. If there is not enough continuous memory in the heap for the request - then malloc will return a NULL. If the allocation was successful then a pointer to the start of the memory is returned. In either case malloc() always returns a pointer to void which assign into out pointer variable.
GOOD PRACTICE: After every call to malloc() - you should test for NULL before using that pointer
In our demo we scanf() into our dynamic string using the same syntax as if reading into an automatic array variable. All of C's string functions are agnostic to whether the incoming string is dynamic or automatic. After initializing and echoing the string - we call free() on the pointer var and then assign a NULL into the pointer.
Question #1: Although many programmers don't do it consistently - Why is it a good idea to assign NULL into a pointer that has just been freed?Some dangers of using dynamic memory
Now that you know how to allocate dynamic memory there are dangers to be understood and avoided. Our first illustration is a caveat that is the inverse of our dangling reference or stale pointer example in the previous chapter. This common misuse of dynamic memory is called a memory leak.
char *ptr; ptr = malloc( 5 );
In the above scenario we declare a pointer variable ptr that lives in the stack, then malloc a chunk of 5 chars in the heap and store it's address into ptr. We then malloc a new chunk of another 5 bytes in the heap using malloc and store this new chunk's address in ptr.
ptr = malloc( 5 );
What happens to the memory allocated at address 1000? Nothing happens to it - and nothing ever will because we have overwritten our only pointer to that memory. There is no garbage collection in C and so this memory is still marked as in-use and cannot be given out to any other calls to malloc. The chunk is wasted. This is a memory leak. Leaking memory is not a memory error per-se. It is however a bad practice that might cause your program to run out of memory. Garbage collection is a function of the runtime environment that watches for cases where memory is allocated but no pointer variable has its address. In this case the runtime environment realizes that this memory is inaccessible and will de allocate that chunk of memory at its earliest convenience.
It is natural to ask: "Why doesn't C implement garbage collection? It sure would save a lot of careless programmers from running out of memory." The reason is efficiency. Some languages, like Java, do have garbage collection. However the performance hit can be significant. In fact this performance hit can make the difference between whether a language is suitable for some application or not. Consider a program that must react in strict real-time to rapidly changing physical events. It is quite possible that time required by garbage collection could occur just at a moment when the program needs to react to an event. Garbage collection from the heap is not a constant time operation. The actual collection operation requires time proportional to the amount of memory being reclaimed. Making the program vulnerable to unexpected interruptions of indeterminate length for a garbage collection algorithm to complete could cause a mission critical failure for a hard real-time application. This is the extreme case against garbage collection. In general having garbage detection running and watching in the background simply slows the program since that garbage detection code has to run every so often just to look for garbage even before an expensive reclamation operation is triggered.
Passing pointers into functions
Our second demo program declares a pointer in main, but wants to initialize that pointer in a function. This requires that the address of the pointer be passed into the function. This is where things get interesting again because the receiving function must prototype a pointer to pointer - the address of the pointer var in main. This introduces the ** notation.
mallocDemo2.c
Our demo2 above accomplishes the same work as demo1 - except- it modifies main's word pointer in a function - rather than in main where the pointer was declared. The data type of the incoming pointer is thus a pointer to a pointer and its prototype is **. Once this is understood we then apply our same rules as passing the address of an int. We simply dereference the local parameter and use it as a synonym for the value of the original pointer in main. When passing the address of any variable just add a star to the prototype of the receiving parameter. Then, once inside the function, dereference that parameter with a single star as a synonym for the original variable from main that you are trying to modify.
Now that we know how to allocate a dynamic string, let's look at pointer arithmetic on automatic and dynamic strings. An important concept to be seen in the following examples is that the string functions and all the syntax used on strings and arrays does not care or make distinction between whether the array or string being operated on is dynamic or automatic. Both types of arrays are treated with the identical syntax. The only differences are that an automatic array's name is not a variable and produces its true dimension when given to the sizeof operator. Other than that, an automatic array's name and a pointer to an array can be dereferenced, indexed and have pointer arithmetic performed on them in identical manner. One last thing. It is not really correct to refer to a pointer to a dynamic array as the array's name. Only an automatic array really has a name. That name is bound to the array's memory for the scope of the array. When the name goes out of scope - so does the array's memory. Dynamic memory is anonymous and it is up to the programmer to retain's the array's address in a pointer at all times until it is freed.
Our third demo declares an array of pointers, and passes that array into a function that will malloc strings to those pointers. The array of pointers itself is automatic storage but the strings hanging off the pointers are dynamic. Note this scheme still suffers from unused rows (pointers) but the length of each string is just enough to store that string.
mallocDemo3.c and input3.txt
The memory allocated in demo three looks like this
Note that when we free the memory associated with this structure we free only the strings and not the array itself since the array is automatic. Only the strings are dynamic.
Our fourth demo allocates a dynamic array of pointers to the exact dimension that will be used, then mallocs dynamic strings to each of the pointers. Note this scheme solves both horizontal and vertical storage waste problems.
mallocDemo4.c and input4.txt
The memory allocated in demo four looks like this:
Note that we draw an arrow out of the wordArray variable box to the beginning of the array. This is just to emphasize that wordArray is a variable not a const. Furthermore the array itself is dynamic as well as the strings hanging off the array. When we free the memory - notice that we free the strings first and the array itself second.
Question #2: WHY: do we free the strings first and the array after? What happens if we do it in reverse order?
Compile time 2D Array of char vs. Dynamic array of pointer
2D array of char (array of strings)
#define MAX_WORDS 10 #define MAX_WORDLEN 15 int main() { char wordArray[MAX_WORDS][MAX_WORDLEN]; /* assume only 5 words ("horses", "cats", "rats", "dogs", "bats") were read into the array */ }The memory allocated for wordArray looks like this: (symbol means '\0' )
The disadvantages of the 2D char array are:
- The amount of space allocated per word is always MAX_WORDLEN while the average word's actual length is much less. Thus, most of the storage is wasted.
- The number of rows in the array must be a compile time constant.
Thus:
- either a large compile time constant must be chosen so as to accommodate the largest possible expected input
- or the program must be modified and recompiled with a larger constant to accommodate larger inputs.
Dynamic Array of pointers: (Demo #4) Solves both problems
If we assume an input file as follows:
5 horses cats rats dogs bats
The memory allocated for wordArray now looks like this
The advantage to the dynamic array is obvious. We dimension it at runtime as soon as we read the expected wordCount from the file.
FYI: Your Lab #3 assignment will NOT have a number at the top of the input files to tell you how to dimension the dynamic array of pointers. Instead - Lab3 requires that you initialize your array to some default dimension, then whenever your array gets full, you must resize your array by doubling its capacity, copy the old pointers into the new array and then free the old array.
Question #3: What is the expected usage/waste over all input sizes of a dynamic array that doubles its size every time it gets full?
Answers to questions:
- Because you can always test for NULL before using a pointer to prevent using a bad pointer.
- If we delete the array of pointers first, the variable wordArray becomes stale and we needed it to access the individual pointers in the array. Dynamic, non-linear data structures should be freed from the leaves, back up to the root. You free the dependent memory before freeing the memory it depends in.
- 25%. Consider that every time we resize the array to size N, we are just as likely to read only one more input as we are to read one short of filling it up again. Thus on average over all input sizes we only fill up half of the new space after a resize. Half of half is 25%. Thus on average we waste 25% space. Of course we can always do one last resize to exact fit.
We now look at our first demonstration of allocation, initialization and deallocation of dynamic memory.
mallocDemo1.c
Dynamic memory is anonymous memory. It has no name. For this reason we don't refer to a pointer to a dynamic chunk (array) as the name of the array. Contrast this with automatic variables which have a name bound to them for life. Every time we call malloc() we must have a pointer variable ready to store the address value returned by malloc()or we have just allocated memory that is inaccessible. This situation is called a memory leak (a.k.a. creating garbage). Another common way to leak memory is to store the address of the array in the pointer, but later overwrite the value in that pointer before you call free on the pointer (which frees what it points to).
Chapter 4.4 Dynamic solution to buffer overflow
We will now use dynamic memory to solve our buffer overflow vulnerability when reading strings. We want a solution that reads an entire line of text with no fear of overflow or truncation. The strategy is simple to explain. Allocate a small dynamic string (array of char). Use fgets() to read as much as will fit in the buffer up to the newline (end of line) or end of file (EOL or EOF). If neither EOL nor EOF has been reached then we know our read was truncated because our array was not big enough. If this is the case we allocate a bigger (doubled in size) array and copy all the chars from our smaller array into the new array. Once we have copied the chars to the new array we free the old array. Now we can read again from the file right where we left off. It is important that not only do we resume reading from the file where the last read left off - we also must store our next read into the array at the place (index) in the array where we left off putting characters. This process repeats until we encounter EOL or EOF.
Here is an illustration of a simplified version of an algorithm that does not trim whitespace or do any kind or error testing/recovery. It just starts with a small buffer and does repeated fgets() reads from the file until it reaches EOL or EOF. After each read attempt it allocates an array twice as big and tries again where it left in the file and the array until EOL or EOF is encountered.
int buffSiz = 10;
char *buffer = malloc(buffSiz);
1 2
01234567890123456789012345678
inFile: [one two three four five six \n]
^
|
read cursor
------------------------------------------ READ #1:
fgets( buffer, buffSiz, inFile);
and now the buffer looks like:
buffer[0] 'o'
buffer[1] 'n'
buffer[2] 'e'
buffer[3] ' '
buffer[4] 't'
buffer[5] 'w'
buffer[6] 'o'
buffer[7] ' '
buffer[8] 't'
buffer[9] '\0'
and the read cursor on the input file is pointing at the 'h' in "three"
1 2
01234567890123456789012345678
inFile: [one two three four five six \n]
^
|
read cursor
Our first read did NOT store a newline, nor have we reached EOF, so we know the input may have been truncated and we need to read again.
We must realloc our string to double its size
buffSiz *= 2;
buffer = realloc( buffer, buffSiz );
and now the buffer looks like:
buffer[0] 'o'
buffer[1] 'n'
buffer[2] 'e'
buffer[3] ' '
buffer[4] 't'
buffer[5] 'w'
buffer[6] 'o'
buffer[7] ' '
buffer[8] 't'
buffer[9] '\0'
buffer[10] '?'
buffer[11] '?'
buffer[12] '?'
buffer[13] '?'
buffer[14] '?'
buffer[15] '?'
buffer[16] '?'
buffer[17] '?'
buffer[18] '?'
buffer[19] '?'
------------------------------------------ READ #2:
fgets( buffer+strlen(buffer), buffSiz-strlen(buffer), inFile); Whatever chars we read in get stored starting over top of the terminating null of the last read
and now the buffer looks like:
buffer[0] 'o'
buffer[1] 'n'
buffer[2] 'e'
buffer[3] ' '
buffer[4] 't'
buffer[5] 'w'
buffer[6] 'o'
buffer[7] ' '
buffer[8] 't'
buffer[9] 'h'
buffer[10] 'r'
buffer[11] 'e'
buffer[12] 'e'
buffer[13] ' '
buffer[14] 'f'
buffer[15] 'o'
buffer[16] 'u'
buffer[17] 'r'
buffer[18] ' '
buffer[19] '\0'
and the read cursor on the input file is pointing at the 'f' in "five"
1 2
01234567890123456789012345678
inFile: [one two three four five six \n]
^
|
read cursor
Our second read did NOT store a newline, nor have we reached EOF so we know the input may have been truncated and we need to read again.
We must realloc our string to double its size
buffSiz *= 2;
buffer = realloc( buffer, buffSiz );
and now the buffer looks like:
buffer[0] 'o'
buffer[1] 'n'
buffer[2] 'e'
buffer[3] ' '
buffer[4] 't'
buffer[5] 'w'
buffer[6] 'o'
buffer[7] ' '
buffer[8] 't'
buffer[9] 'h'
buffer[10] 'r'
buffer[11] 'e'
buffer[12] 'e'
buffer[13] ' '
buffer[14] 'f'
buffer[15] 'o'
buffer[16] 'u'
buffer[17] 'r'
buffer[18] ' '
buffer[19] '\0'
buffer[20] ?
buffer[21] ?
buffer[22] ?
buffer[23] ?
buffer[24] ?
buffer[25] ?
buffer[26] ?
buffer[27] ?
buffer[28] ?
buffer[29] ?
buffer[30] ?
buffer[31] ?
buffer[32] ?
buffer[33] ?
buffer[34] ?
buffer[35] ?
buffer[36] ?
buffer[37] ?
buffer[38] ?
buffer[39] ?
------------------------------------------ READ #3:
fgets( buffer+strlen(buffer), buffSiz-strlen(buffer), inFile); Whatever chars we read in get stored starting over top of the terminating null of the last read
buffer[0] 'o'
buffer[1] 'n'
buffer[2] 'e'
buffer[3] ' '
buffer[4] 't'
buffer[5] 'w'
buffer[6] 'o'
buffer[7] ' '
buffer[8] 't'
buffer[9] 'h'
buffer[10] 'r'
buffer[11] 'e'
buffer[12] 'e'
buffer[13] ' '
buffer[14] 'f'
buffer[15] 'o'
buffer[16] 'u'
buffer[17] 'r'
buffer[18] ' '
buffer[19] 'f'
buffer[20] 'i'
buffer[21] 'v'
buffer[22] 'e'
buffer[23] ' '
buffer[24] 's'
buffer[25] 'i'
buffer[26] 'x'
buffer[27] ' '
buffer[28] '\n'
buffer[29] '\0'
buffer[30] ?
buffer[31] ?
buffer[32] ?
buffer[33] ?
buffer[34] ?
buffer[35] ?
buffer[36] ?
buffer[37] ?
buffer[38] ?
buffer[39] ?
Our third read DID store a newline so we know we got the whole line. We are done. Even if the input file only contained this one line and there was no newline at end we would have detected EOF and still concluded that we are done reading this line.