The NULL Value and Pointer Errors

The stdio.h header includes a handy value, NULL, that we can use whenever we need to talk about an “empty” or uninitialized pointer. You can assign NULL to a pointer variable or use it in a comparison to see if a particular pointer is valid. If you like always assigning an initial value to your variables when you declare them, NULL is the value to use with pointers. For example, we could declare two variables, one double and one pointer to a double. We’ll initialize them with “nothing,” but then fill them in later:

double pi = 0.0;
double *pi_ptr = NULL;
// ...
pi = 3.14156;
pi_ptr = π

You should check for NULL pointers anytime you can’t trust where a pointer came from. Inside a function where a pointer was passed to you, for example:

double messyAreaCalculator(double radius, double *pi_ptr) {
  if (pi_ptr == NULL) {
    printf("Could not calculate area with a reference to pi!
");
    return 0.0;
  }
  return radius * radius * (*pi_ptr);
}

Not the easiest way to calculate the area of a circle, of course, but the if statement at the beginning is a common pattern. It’s a simple guarantee that you have something to work with. If you forget to check your pointer and try dereferencing it anyway, your program will (usually) halt, and you’ll probably see an error like this:

Segmentation fault (core dumped)

Even if you can’t do anything about the empty pointer, if you check before using it, you can give the user a nicer error message and avoid crashing.

Arrays

What about arrays and strings? Will those go on the stack just like simpler types? Will they have addresses in the same general part of memory? Let’s create a couple array variables and see where they land and how much space they take up. ch06/address3.c has our arrays. I’ve added a size printout so that we can easily verify how much space is allocated:

#include <stdio.h>

int main() {
  char title[30] = "Address Example 3";
  int page_counts[5] = { 14, 78, 49, 18, 50 };
  printf("title's value: %s
", title);
  printf("title's address: %p
", &title);
  printf("title's size: %lu
", sizeof(title));
  printf("page_counts' value: {");
  for (int p = 0; p < 5; p++) {
    printf(" %d", page_counts[p]);
  }
  printf(" }
");
  printf("page_counts's address: %p
", &page_counts);
  printf("page_counts's size: %lu
", sizeof(page_counts));
}

And here is our output:

title's value: Address Example 3
title's address: 0x7ffe971a5dc0
title's size: 30
page_counts' value: { 14 78 49 18 50 }
page_counts's address: 0x7ffe971a5da0
page_counts's size: 20

The compiler rearranged our variables again, but we can see that the page_counts array is 20 bytes (5 x 4 bytes per int) and that title gets an address 32 bytes after page_counts. (You can ignore the common parts of the address and do a little math: 0xc0 – 0xa0 == 0x20 == 32.) So what’s in the extra 12 bytes? There is some overhead for an array, and the compiler has kindly made room for it. Happily, we (as programmers or as users) do not have to worry about that overhead. And as programmers we can see the compiler definitely sets aside enough room for the array itself.

Local Variables and the Stack

So where exactly is that “room” being set aside? In the largest terms, the room is allocated from our computer’s memory, its RAM. In the case of variables defined in a function (and remember from “The main() Function” that main() is a function), the space is allocated on the stack. That’s the term for the spot in memory where all local variables are created and kept as you make various function calls. Organizing and maintaining these memory allocations is one of the primary jobs of your operating system.

Consider this next small program, ch06/do_stuff.c. We have the main() function as usual, and another function, do_stuff(), that, well, does stuff. Not fancy stuff, but it still creates and prints the details of an int variable. Even boring functions use the stack and help illustrate how function calls fit together in memory!

#include <stdio.h>

void do_stuff() {
  int local = 12;
  printf("Our local variable has a value of %d
", local);
  printf("local's address: %p
", &local);
}

int main() {
  int count = 1;
  printf("Starting count at %d
", count);
  printf("count's address: %p
", &count);
  do_stuff();
}

And here’s the output:

ch06$ gcc do_stuff.c
ch06$ ./a.out
Starting count at 1
count's address: 0x7fff30f1b644
Our local variable has a value of 12
local's address: 0x7fff30f1b624

You can see the addresses of count in main() and local in do_stuff() are near each other. They are both on the stack. Figure 6-2 shows the stack with a little more context.

Figure 6-2. Local variables on the stack

This is where the name “stack” comes from: the function calls stack up. If do_stuff() were to call some other function, that function’s variables would pile on top of local. And when any function completes, its variables are popped off the stack. That stacking can go on quite awhile, but not forever. If you don’t provide a proper base case for a recursive function like those in “Recursive Functions”, for example, this runaway stack allocation is what eventually causes your program to crash.

You might have caught that the addresses in Figure 6-2 are actually decreasing. The start of the stack can either be at the beginning of the memory allocated to our program and addresses will count up, or at the end of the allotted space and addresses will count down. Which version you see depends on the architecture and operating system. The idea of the stack and its growth, though, remains the same.

The stack also houses any parameters that get passed to a function as well as any loop or other variables that get declared later in the function. Consider this snippet:

float average(float a, float b) {
  float sum = a + b;
  if (sum < 0) {
    for (int i = 0; i < 5; i++) {
      printf("Warning!
");
    }
    printf("Negative average. Be careful!
");
  }
  return sum / 2;
}

In this snippet, the stack will include space for the following elements:

• the float return value from average() itself

• the float parameter a

• the float parameter b

• the float local variable sum

• the int variable i for the loop (only if sum < 0)

The stack is pretty versatile! Pretty much anything having to do with a particular function will get its memory from the stack.

Global Variables and the Heap

But what about global variables that are not connected to any particular function? They get allocated in a separate part of memory called the heap. If “heap” sounds a little messy, it is. Any bit of memory your program needs that isn’t part of the stack will be in the heap. Figure 6-3 illustrates how to think about the stack and the heap.

Figure 6-3. Stack versus heap memory

The stack and the heap share one logical lump of memory given to your program when you run it. As you make function calls, the stack will grow (down from the “top” in this case). As functions complete their call, the stack shrinks. Global variables make the heap grow (up from the “bottom”). Large arrays or other structures may also be allocated in the heap. (“Managing Memory with Arrays” in this chapter looks at how you can manually use memory in this space.) You can free up some parts of the heap to make it shrink, but global variables remain as long as your program is executing.

We’ll look in more detail at how these two parts of memory interact in “Stacks and heaps”. As both the stack and the heap grow, the free space in the middle gets smaller and smaller. If they meet, you’re in trouble. If the stack cannot grow any further, you won’t be able to call any more functions. If you call a function anyway, you will likely crash your program. Similarly, if there is no space left for the heap to grow, but you try to request some space, the computer has no choice but to halt your program.

Managing to stay out of this trouble is your job as the programmer. C won’t stop you from making a mistake, but in turn, it gives you room to be quite clever when circumstances dictate. Chapter 10 looks at several of those circumstances on microcontrollers and discusses some tricks for navigating them.

Allocating with malloc()

While we’ll typically reserve heap work for larger arrays, you can allocate anything you want there. To do so, you use the malloc() function and provide it a quantity in bytes that you need. The malloc() function is defined in another header, stdlib.h, so we have to include that header, similar to how we include stdio.h. We’ll see more of the functions that stdlib.h provides in “stdio.h”, but for now, just add this line at the top, below our usual include:

#include <stdio.h>
#include <stdlib.h>

// ...

With this header included, we can create a simple program that illustrates the memory allocation of global and local variables as well as our own, custom bit of memory in the heap. Take a look at ch06/memory.c:

#include <stdio.h>
#include <stdlib.h>

int result_code = 404;
char result_msg[20] = "File Not Found";

int main() {
  char temp[20] = "Loading ...";
  int success = 200;

  char *buffer = (char *)malloc(20 * sizeof (char));

  // We won't do anything with these various variables,
  // but we can print out their addresses
  printf("Address of result_code:   %p
", &result_code);
  printf("Address of result_msg:    %p
", &result_msg);
  printf("Address of temp:          %p
", &temp);
  printf("Address of success:       %p
", &success);
  printf("Address of buffer (heap): %p
", buffer);
}

The global declarations of result_code and result_msg as well as the local variables temp and success should be familiar. But look at how we declared buffer. You can see the use of malloc() in a real program. We asked for 20 characters of space. You can specify a simple number of bytes if you want, but it is usually safer (indeed, often necessary) to use sizeof, as shown in this example. Different systems will have different rules regarding type sizes and memory allocation, and sizeof provides an easy guard against unwitting mistakes.

Let’s take a look at the addresses of our variables in the output:

ch06$ gcc memory.c
ch06$ ./a.out
Address of result_code:   0x55c4f49c8010
Address of result_msg:    0x55c4f49c8020
Address of temp:          0x7fffc84f1840
Address of success:       0x7fffc84f1834
Address of buffer (heap): 0x55c4f542e2a0

Again, don’t worry about the exact value of those addresses. What we’re looking for here is their general location. Hopefully, you can see that the global variables and the buffer pointer we created in the heap manually with malloc() are all in roughly the same spot. Likewise, the two variables local to main() are similarly grouped, but in a separate spot.

So malloc() makes room for your data in the heap. We’ll make use of this allocated space in “Pointers to Structures”, but we need to look at a closely related function, free(), first. When you allocate memory using malloc(), you are responsible for returning that space when you are done.

Deallocating with free()

As you might recall in the discussion of Figure 6-3, if you use up too much of the stack or the heap—or enough of both—you will run out of memory and your program will crash. One of the benefits of working with the heap is that you have control over when and how memory is allocated from and returned to the heap. Of course, as I just noted, the flipside of this benefit is that you have to remember to do the “giveing back” part yourself. Many newer languages work to relieve the programmer of that burden, as it is all too easy to forget to clean up after yourself. Perhaps you have even heard of the quasi-official term for this issue: a memory leak.

To return memory and avoid such leaks in C, you use the free() function (also from stdlib.h). It’s pretty straightforward to use—you just pass the pointer returned from your corresponding malloc() call. So to free up buffer when you’re done using it, for example:

  free(buffer);

Easy! But again, it’s remembering to use free() that is the difficulty. That might not seem like such a problem, but it gets increasingly tricky when you start using functions to create and remove bits of data. How many times did you call the create functions? Did you call a reciprocal remove function for each one? What if you try to remove something that was never allocated? All of these questions make keeping track of your memory usage as troublesome as it is vital.

Assigning and Accessing Structure Members

Once your structure type is defined, you can declare and initialize variables of that type using syntax similar to how we handle arrays. For example, if you know a structure’s values ahead of time, you can use curly braces to initialize your variable:

  struct transaction deposit = { 200.00, 6, 20, 2021 };

The order of the values inside the braces needs to match the order of the variables you listed in the struct definition. But you can also create a structure variable and fill it in after the fact. To indicate which field you want to assign, you use the “dot” operator. You give the structure variable’s name (bill or deposit in our current example), a period, and then the member of the structure you are interested in, like day or amount. With this approach, you can make assignments in any order you like:

  bill.day = 15;
  bill.month = 7;
  bill.year = 2021;
  bill.amount = 56.75;

Regardless of how you filled the structure, you use the same dot notation to access a structure’s contents anytime you need them. For example, to print any details from a transaction, we specify the transaction variable (bill or deposit in our case), the dot, and the field we want, like this:

  printf("Your deposit of $%0.2f was accepted.
", deposit.amount);
  printf("Your bill is due on %d/%02d
", bill.month, bill.day);

We can print these inner elements to the screen. We can assign new values to them. We can use them in calculations. You can do everything with the pieces inside your structure that you do with other variables. The point of the structure is simply to make it easier to keep related pieces of data together. But these structures also keep data distinct. Consider assigning the amount variable in both our bill and our deposit:

  deposit.amount = 200.00;
  bill.amount = 56.75;

There is never any confusion over which amount you mean, even though we used the amount name in both assignments. If we add some tax to our bill after it was set up, for example, that will not affect how much money we include in our deposit:

  bill.amount = bill.amount + bill.amount * 0.05;

  printf("Our final bill: $%0.2f
", bill.amount); // $59.59
  printf("Our deposit: $%0.2f
", )                // $200.00

Hopefully, that separation makes sense. With structures, you can talk about bills and deposits as entities in their own right, while understanding that the details of any individual bill or deposit remain unique to that transaction.

Pointers to Structures

If you build a good composite type that encapsulates just the right data, you will likely start using these types in more and more places. You can use them for global and local variables or as parameter types or even function return types. In the wild, however, you will more often see programmers working with pointers to structures rather than structures themselves.

To create (or destroy) pointers to structures, you can use exactly the same operators and functions that are available for simple types. If you already have a struct variable, for example, you can get its address with the & operator. If you created an instance of your structure with malloc(), you use free() to return that memory to the heap. Here are a few examples of using these features and functions with our struct transaction type:

struct transaction tmp = { 68.91, 8, 1, 2020 };
struct transaction *payment;
struct transaction *withdrawal;

payment = &tmp;
withdrawal = malloc(sizeof(struct transaction));

Here, tmp is a normal struct transaction variable and we initialize it using curly braces. Both payment and withdrawal are declared as pointers. We can assign the address of a struct transaction variable like we do with payment, or we can allocate memory on the heap (to fill in later) like we do with withdrawal.

When we go to fill in withdrawal, however, we have to remember that we have a pointer, so withdrawal requires dereferencing before we can apply the dot. Not only that, the dot operator has a higher order of precedence than the dereference operator, so you have to use parentheses to get the operators applied correctly. That can be a little tedious, so we often use an alternate notation for accessing the members of a struct pointer. The “arrow” operator, ->, allows us to use a struct pointer without dereferencing it. You place the arrow between the structure variable’s name and the name of the intended member just like with the dot operator:

// With dereferencing:
(*withdrawal).amount = -20.0;

// With the arrow operator:
withdrawal->day = 3;
withdrawal->month = 8;
withdrawal->year = 2021;

This difference can be a little frustrating, but eventually you’ll get used to it. Pointers to structures provide an efficient means of sharing relevant information between different parts of your program. Their biggest advantage is that pointers do not have the overhead of moving or copying all of the internal pieces of their structures. This advantage becomes apparent when you start using structures with functions.

Functions and Structures

Consider writing a function to print out the contents of a transaction in a nice format. We could pass the structure as is to a function. We just use the struct transaction type in our parameter list and then pass a normal variable when we call it:

void printTransaction1(struct transaction tx) {
  printf("%2d/%02d/%4d: %10.2f
", tx.month, tx.day, tx.year, tx.amount);
}
// ...
printTransaction1(bill);
printTransaction1(deposit);

Pretty simple, but recall our discussion of how function calls work with the stack. In this example, all of the fields of bill or deposit will have to be put on the stack when we call printTransaction1(). That takes extra time and space. Indeed, in the very earliest versions of C, this wasn’t even allowed! That’s obviously not true any longer, but passing pointers to and from functions is still faster. Here’s a pointer version of our printTransaction1() function:

void printTransaction2(struct transaction *ptr) {
  printf("%2d/%02d/%4d: %10.2f
",
      ptr->month, ptr->day, ptr->year, ptr->amount);
}
// ...
printTransaction2(&tmp);
printTransaction2(payment)
printTransaction2(withdrawal);

The only thing required to go on the stack was the address of one struct transaction object. Much cleaner.

Passing pointers this way has an interesting, intended feature: we can change the contents of a structure in the function. Recall from “Passing Simple Types” that without pointers, we end up passing values via the stack that initialize the parameters of the function. Nothing we do to those parameters while inside the function affects the original arguments from wherever the function was called.

If we pass a pointer, however, we can use that pointer to change the insides of the structure. And those changes persist because we are working on the actual structure, not a copy of its values. For example, we could create a function to add tax to any transaction:

void addTax(struct transaction *ptr, double rate) {
  double tax = ptr->amount * rate;
  ptr->amount += tax;
}

// ... back in main
  printf("Our bill amount before tax: $%.2f
", bill.amount);
  addTax(&bill, 0.05);
  printf("Our bill amount after tax: $%.2f
", bill.amount);
// ...

Notice that we do not change bill.amount in the main() function. We simply pass its address to addTax() along with a tax rate. Here’s the output of those printf() statements:

Our bill amount before tax: $56.75
Our bill amount after tax: $59.59

Exactly what we were hoping for. Because it proves so powerful, passing structures by reference is very common. Not everything needs to be in a structure, and not every structure has to be passed by reference, but in large programs, the organization and efficiency you get are definitely appealing.