Understanding Pointers (with Lego) Part 1

Ahhh pointers.

I’ve been wanting to write a series of posts on pointers for a long time. When I’ve finished, I’ll upload a complete PDF eGuide. In the meantime, enjoy 🙂


A concept that some programmers avoid through fear, others abuse through ignorance, and yet others manage to use with grace and efficiency.

Every programmer who does more than dabble in C and C++ needs to understand this subject. Properly.

This is Part 1 of a multi-part series, and there will be a lovely quiz at the end, which I expect you will all get 100% on after reading my posts, right?

Let’s crack on.

Read moreUnderstanding Pointers (with Lego) Part 1

How To Compile a 32-bit Executable on 64-bit Fedora 19

You know how sometimes you just have to compile and run a 32 bit program on a 64 bit machine, and it’s really annoying that it doesn’t seem to work?

Yeah, me too.

Turns out it’s actually pretty straightforward on Fedora 19.

First of all, you need to use the -m32 build flag. Below I’m using it to compile my program ‘pointers’:

gcc -m32 pointers.c -o pointers

You may run into the following error:

/usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
# include <gnu/stubs-32.h>
compilation terminated.

To fix this you need to install the 32 bit glibc-devel package. You can do this by running:

yum install glibc-devel.i686

Next, you might see this error:

/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/4.8.2/libgcc_s.so when searching for -lgcc_s
/usr/bin/ld: cannot find -lgcc_s
collect2: error: ld returned 1 exit status

Which means you need to install the 32 bit standard C++ library package. You can do this by running:

yum install libstdc++-devel.i686

Then you can quite happily compile your executable with the -m32 flag, as above:

gcc -m32 pointers.c -o pointers

And, as if by magic, you get a 32 bit exe that runs on your 64 bit machine.

You can use the file command to admire what you’ve made:

[faye@localhost src]$ file pointers
pointers: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), 
for GNU/Linux 2.6.32, BuildID[sha1]=0x39958fed2f5c099ad97fd7512e780066acfb1231, not stripped

Eclipse CDT + GDB: Setting Watchpoints (Juno)

I was trying to watch a variable in Eclipse today and just could not find how to set it up. No matter what I did the Toggle Watchpoint option remained greyed out.

A watchpoint is more fun than a regular breakpoint, because the debugger will stop whenever the variable is changed, even if your program is busy doing something else (like overrunning the end of an array).

So after a bit of research it turns out that you can set watchpoints, but the variable type dictates how.

Global variables

If your variable is global, you need to double-click the variable to highlight it (anywhere in your source) and then select Run > Toggle Watchpoint. Until your variable is selected, this option will always be greyed out.

You can also right click on it in the Outline View and then select Toggle Watchpoint from the context menu.

In both cases a watchpoint properties box pops up so you can edit the details. Just click OK and the debugger will stop every time the variable is changed.

If the variable is not listed in the Outline View then sorry – it’s not global and you can’t use the Eclipse GUI to set it – but you can do this:

Local variables

When you’re debugging with gdb via Eclipse, there is a sneaky gdb console view that you can use to talk directly to the gdb session.

Select the console tab at the bottom and on the right-hand side click the Display Selected Console button. This will reveal a drop down menu. Choose [C/C++ Application] gdb.

And now, in the console itself, just type your watchpoint as if you were on the gdb command line (in the screenshot below I want to be notified if a local variable called count goes above the value of 45):


gdb console watchpoint

Ta da! Eclipse will now stop whenever your local variable changes.

Unions in C

Unions – ew.

As primarily a C++ programmer, I used to shy away from code that contained this kind of black magic. However, unions are actually very cool things and are really not that scary or weird.

A union is basically a variable. But instead of being an int, or a float, or a double, a union can actually be any one of these things at a given point in time.

What? That doesn’t make any sense!

Wait – let me illustrate with an example.

The code below contains a union declaration at the top. Unions are declared just like structs, but instead of containing ALL the variables listed, a union only contains enough space for the largest one.

So in my example, where the union contains an int and a char – how big do you think will it be?

That’s right, it will be a single variable the same size as an int, because an int is larger than a char.

Storing and accessing union data is done just like it is with a struct:

#include <stdio.h>

int main()
    union ascii
        int number;
        char symbol;
    } a;

    /* Incoming data - could come from a variety of sources: */

    a.symbol = 'x';
    a.number = 120; 

    /* output last type in (int) */
    printf("Variable a is set to %d\n", a.number);

    return 0;

Okaaay… but how do you know what it is when it can be multiple things?

Good question. You can’t actually tell what is inside a union, but the rule is that whatever you put in last, will be what you get out, and it is YOUR responsibility to remember what it was.

The best way to do this is with a variable that you update to contain the correct type (use an enum of INT, FLOAT, etc.)

If you access a union using a type that isn’t the same as the one last stored, what you get back is undefined.

Unions are really useful when you want to save storage space (especially good in embedded programming), or if you are receiving data that may arrive in different types (but which is essentially being used for the same purpose).

See? Not so scary after all.