Such Programming

Tinkerings and Ramblings

Fun With Pointers

Pointers are one of the most misunderstood concepts in C but also one the most powerful tools it provides. In general they are just numbers in memory like everything else, but their value is interpreted as an address to other data. In this document I’ll attempt to demystify the arcane pointer and show some practical examples of their power.


Everything Lives In Memory

Before I get into pointers, I want to clarify some aspects of how a program runs. This will all be based on my local Linux environment so your mileage may vary, but conceptually it’s all the same.

The C compiler and linker you use takes your code, parses it, and converts it to a binary file that works for the targeted processor and operating system. The compiler will validate your C code and generate machine code that your processor can work with, the linker will do some organizational tasks to allow your program to use libraries and be loaded by the operating system.

Most, if not all, UNIX systems use the Executable and Linkable Format (ELF) for compiled programs and libraries. It has a header that describes what type of binary the file is, and has a lot of other data that tells the operating system where in virtual memory the program’s assets should be loaded.

Here’s a simple program that we’ll inspect a little bit. It spits out the addresses of a few things, the locations in the running virtual memory space of a program. The & operator before a variable will give you the address of that variable.

#include <stdio.h>

int my_global = 123;

int main(void)
  int my_local = 456;

  printf("main has an address, it is %p\n", main);
  printf("my_global has an address, it is %p\n", &my_global);
  printf("my_local has an address, it is %p\n", &my_local);
  printf("printf has an address, it is %p\n", printf);
  return 0;

Tons of crap ends up in the binary for a C program, like all the stuff that provides you the goodness of the standard C library and the stuff the C library itself needs. One of the more interesting things we can look at is the symbol table. Symbols help give us names to find important things in the program. I’ll use readelf to dump the symbol table from the binary, and filter out globals.

From this list there are a few things that were defined in my source file. Entries 4 and 53 both refer to the printf call I’m using from glibc which for this program is located at the memory address 0x400470, entry 59 is the my_global variable from my program at the address 0x601040 and entry 64 is my main function at 0x400596. The only thing missing is the my_local variable that’s inside of my main function.

If I run the program a few times I’ll see where the program says these things are.

As seen here, main, my_global and printf all have consistent locations in memory and it matches what was listed in the symbol table, while my_local changes between calls of the program. This is because the local variable is part of the function which is part of the call stack and Linux uses a security feature that randomizes where the stack begins. As functions are called in your C program the stack is used for function arguments, function local variables and a pointer to code that should be ran after the function is complete. Each function call gets a new section of the stack, referred to as a Stack Frame.

Just like a string and everything else on the computer, the executable code resides somewhere in memory. I can use objdump to get the machine code version of main, and it’ll show us each instruction that main is composed of and the addresses of each processor operation.

0000000000400596 <main>:
  400596:       55                      push   rbp
  400597:       48 89 e5                mov    rbp,rsp
  40059a:       48 83 ec 10             sub    rsp,0x10
  40059e:       64 48 8b 04 25 28 00    mov    rax,QWORD PTR fs:0x28
  4005a5:       00 00 
  4005a7:       48 89 45 f8             mov    QWORD PTR [rbp-0x8],rax
  4005ab:       31 c0                   xor    eax,eax
  4005ad:       c7 45 f4 c8 01 00 00    mov    DWORD PTR [rbp-0xc],0x1c8
  4005b4:       be 96 05 40 00          mov    esi,0x400596
  4005b9:       bf b8 06 40 00          mov    edi,0x4006b8
  4005be:       b8 00 00 00 00          mov    eax,0x0
  4005c3:       e8 a8 fe ff ff          call   400470 <printf@plt>
  4005c8:       be 40 10 60 00          mov    esi,0x601040
  4005cd:       bf d8 06 40 00          mov    edi,0x4006d8
  4005d2:       b8 00 00 00 00          mov    eax,0x0
  4005d7:       e8 94 fe ff ff          call   400470 <printf@plt>
  4005dc:       48 8d 45 f4             lea    rax,[rbp-0xc]
  4005e0:       48 89 c6                mov    rsi,rax
  4005e3:       bf 00 07 40 00          mov    edi,0x400700
  4005e8:       b8 00 00 00 00          mov    eax,0x0
  4005ed:       e8 7e fe ff ff          call   400470 <printf@plt>
  4005f2:       be 70 04 40 00          mov    esi,0x400470
  4005f7:       bf 28 07 40 00          mov    edi,0x400728
  4005fc:       b8 00 00 00 00          mov    eax,0x0
  400601:       e8 6a fe ff ff          call   400470 <printf@plt>
  400606:       b8 00 00 00 00          mov    eax,0x0
  40060b:       48 8b 55 f8             mov    rdx,QWORD PTR [rbp-0x8]
  40060f:       64 48 33 14 25 28 00    xor    rdx,QWORD PTR fs:0x28
  400616:       00 00 
  400618:       74 05                   je     40061f <main+0x89>
  40061a:       e8 41 fe ff ff          call   400460 <__stack_chk_fail@plt>
  40061f:       c9                      leave  
  400620:       c3                      ret    

Don’t be too daunted with the assembly here, we’re not here to talk about that. Just grasp that when this program is running main will be residing here in the memory space of the program.

To the memory, there is no difference between program code and bytes that may be strings, integers or pictures of cats. To prove this, I’ll tell the compiler that I want to use main as a string, and I’ll look at the first character of it.

#include <stdio.h>

int main(void)
  char *string = (char*) main;

  printf("character: %c\n", string[0]);
  printf("hex: %x\n", string[0]);

  return 0;


When I build and run this program, this is what I get:

$ ./test 
character: U
hex: 55

Just like my previous program, main starts with the assembly operation push rbp, which if you look at as an ascii character would be a U, or 0x55 as a hexadecimal number.

Why You Confuse Me So?!

The reason I’m pushing this so hard is to really drive home the fact that everything lives in memory and that the only difference between data types is how you treat the data in memory. You can interpret any given chunk of memory as any type, in the case of pointers we treat a chunk of memory as an address that points to another chunk of memory.

Let’s look at some less esoteric examples of how this can be useful.

The Great Unknown

For someone writing a C application, it would be fantastic if you knew how much memory a program would use before running it. Sadly this is almost never the case, so we need ways to get more memory when we need it. The call stack can suffice to create space for the variables we use inside of a function, but when the function ends we lose scope of those variables. To dynamically allocate space for keeps we use the heap, most commonly via malloc() (memory allocate).

The malloc() function is provided by the C standard library, it asks the operating system to give your program a chunk of memory to work on. This is useful for making space as needed to store data in your program.

Here’s an example, this program will take a number of bytes to allocate. It’ll request a chunk of memory of that size, print out it’s address, and then releases that chunk of memory back to the system (to avoid memory leaks!.

#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[])
	void *dynamic_space;
	int size;
	if(argc != 2)
		fprintf(stderr, "Usage: %s <number of bytes to allocate>\n", argv[0]);
		return 1;
	size = atoi(argv[1]);
	if(size < 1)
		fprintf(stderr, "Number of bytes must be larger than 0\n");
		return 1;
	dynamic_space = malloc(size);
	printf("We allocated %d bytes, they are located at %p\n", size, dynamic_space);
	return 0;

I’ll give this program a few runs asking for different amounts of memory

As you can see, the memory gets allocated in a variety of places even if you ask for the same amount of memory on another run of the program. On my machine, when I asked for a huge allocation it provided me a much higher memory address to use. I’m not sure why this happened but if the system thinks that’s where it should be who am I to argue.

It’s easy enough to ask for space dynamically, the new problem introduced by this is how to be organize it all.

Pointer Usage

There is no one perfect way to organize your pointers, but there are a ton of tried and true methods that are useful for a variety of cases.

Null terminated arrays

One of most common structures is a null terminated array, in the case of the char type we normally just call this a string. One of the handy things about these types of structures is they allow for pointer arithmetic. A null terminated array is a contiguous block of memory that contains no information about it’s size, but you can find the end of it by looking for the NULL or 0 (same thing in C) value at the end of it.

In C the ++ and -- operators work to increment and decrement values, but in the case of pointers they increment by the size of the data type the pointer works with, so it’s identical to incrementing a number with character pointers since characters use a single byte, but for a 4 byte integer it’s more like +=4. Using this functionality you can loop through a null terminated list until the value the pointer points to is zero pretty easily.

Here’s an example of that:

#include <stdio.h>
char my_string[] = "well hello there";
int many_numbers[] = {1, 2, 3, 0};
int main(int argc, char *argv[]) {
  char *a_character; 
  int *an_integer;
  // Start where my_string points, printing each character until a_character
  // points to a zero value
  for(a_character = my_string; *a_character; a_character++) {
    printf("at %p we have '%c'\n", a_character, *a_character);
  for (an_integer = many_numbers; *an_integer; an_integer++) {
    printf("at %p we have %d\n", an_integer, *an_integer);
  return 0;

And here’s that program in action

As you can see the address is incremented by 1 for character pointers and 4 for integer pointers. We can keep reading as long as the dereferenced value (the value in the address the pointer points to) is not zero. When it is zero we’re at the end of the array.

To drive this home further, here’s a program that’ll determine the length of a string given as the first argument.

#include <stdio.h>
int main(int argc, char *argv[]) {
	int size = 0;
	char *ptr;
	if (argc != 2) {
		fprintf(stderr, "Usage: %s <string>\n", argv[0]);
		return 1;
	ptr = argv[1];
	while (*ptr) {
	printf("first argument is %d bytes long\n", size);
	return 0;

And let’s see how that fares

Passing By Reference

In many languages, we hear about how things are passed by reference, as opposed to things that are passed by value. In many interpreted languages you have little to no control over how that works, but C lets (makes?) you control that completely.

Let’s say I want to make a function that randomizes two numbers for me. In C you can’t return more than one value from a function, so setting two variables with one function call isn’t possible without pointers. I could return an array of two integers that have random values, then set my variables to those values, but that means my function doesn’t do everything I want it to on it’s own.

The easiest way to do this is to pass the addresses (pointers) to the variables I want randomized, then my function can dereference them as if they were ordinary variables with *.

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

void randomize_them(int *a, int *b) {
  *a = random();
  *b = random();

int main(void) {
  int my_a = 1;
  int my_b = 2;

  printf("before\na = %d\nb = %d\n", my_a, my_b);
  randomize_them(&my_a, &my_b);
  printf("after\na = %d\nb = %d\n", my_a, my_b);

  return 0;

Now that wasn’t too bad, was it?

That’ll wrap things up for this post, this covers most of the basics about pointers. I will be covering a bit more pointer-fu in the next post about defining and using structures in C, but I think this provides a good start for now.