Below is a piece of code similar to something I was working with last week. Please bare with me on the simplicity of this example. I know that modern applications should not use 32-bit integers to store IP addresses because of IPv6 compatibility.

#include <stdint.h>
#include <string.h>

typedef struct Address {
    uint32_t ip;
    uint16_t port;
} Address;

typedef struct Entry {
    Address address;
    Connection *connection;
} Entry;

typedef struct Connection Connection;

Connection *FindConnection(const Address *address,
                           Entry *connections,
                           size_t nConnections) {
    for (size_t i = 0; i < nConnections; ++i) {
        if (memcmp(address,
                   &connections[i].address,
                   sizeof *address) == 0) {
            return connections[i].connection;
        }
    }
    return NULL;
}

Have you seen what’s wrong with this function? It seems simple enough. Iterate through an array of entries in some kind of connection table looking for the one with the matching IP address and port number. What could be easier? Let’s use the function now.

Address addr = { 0x7f000001, 80 };
Connection *conn = FindConnections(&addr, conns, nCons);

This code will work most of the time. To see why I said “most of the time” let’s first ask a question: What is sizeof *address in the function above? A quick test program will reveal the answer: 8

This may be a bit surprising but remember that each primitive variable type has an alignment requirement enforced upon it by the underlying architecture. A uint32_t must always have a memory address divisible by 4, a uint16_t must be at an address divisible by 2. If we construct an array of address structs in order for the the uint32_t inside of each to be aligned the compiler must add a little padding in between. Including the padding the size of the entire struct is 8. 6 bytes of data plus 2 bytes of padding. This brings us to the next question: What is the value of these two bytes? To answer this lets look at the assembly generated by the statement that initializes addr above:

movl    $2130706433, -16(%rbp)
movw    $80, -12(%rbp)

The variable addr consists of two values, 2130706433 (which is simply the decimal form of the hexadecimal value 7F000001) and 80. These are copied onto the function’s stack at 16 bytes before the %rbp (which is the stack base pointer) and 12 bytes before %rbp. “movl” copies 4 bytes, a “long word,” and “movw” copies 2 bytes, a word. (For the curious, on x86 8 bytes is a “quad word” and is abbreviated “q” and 1 byte is a “half word” and abbreviated “h”.) Since the struct is 8 bytes long in total we can see that it exists in the 8 bytes between %rbp-16 and %rbp-8. But wait! We’ve only copied 6 bytes! This is where the problem lies. Initializing a struct using this syntax leaves the padding bytes uninitialized. Quoting the C99 specification:

When a value is stored in an object of structure or union type, including in a member object, the bytes of the object representation that correspond to any padding bytes take unspecified values.

Now we understand why this code doesn’t work sometimes. C doesn’t guarantee anything about the padding bytes but in the memcmp call we compare the entire struct, including the padding. Since the padding is uninitialized it could be any two random bytes that happened to be there when the variable was initialized. Most of the time they will be zero but every once in a while they will be something else and the code will mysteriously fail to find a connection entry which may otherwise appear to be present.

How can we catch this before it causes random failures? Running the program under a memory checker such as Valgrind will alert you to comparisons which use uninitialized values. Here’s what the failure looks like:

Conditional jump or move depends on uninitialised value(s)
   at 0x4C2EB32: bcmp (mc_replace_strmem.c:930)
   by 0x400602: FindConnection (test.c:19)
   by 0x4006A7: main (test.c:37)

Valgrind is complaining here that bcmp (which is the function behind memcmp above) is branching based on an uninitialized value. While it causes your application to slow down by a factor of 10 or more Valgrind is a very useful tool for detecting silent errors that may become bugs in the future.

How could we avoid this problem? The first answer is that maybe using memcmp wasn’t a good idea. As we’ve seen using it this way makes some assumptions about how the compiler is laying out memory that might not hold true in all circumstances. Explicitly comparing the IP and port fields will generate the correct code and may actually be faster since it isn’t calling a generic function like memcmp. Another way to avoid this is to make the padding bytes explicit like this:

typedef struct Address {
    uint32_t ip;
    uint16_t port;
    uint16_t padding;
} Address;

Why does this make a difference? First, the structure is still 8 bytes. All of the uint32_t’s can easily fall on 4 byte boundaries and uint16_t’s on 2 byte boundaries. Does the initialization style we used above still work? Yes. C allows struct initialization to omit some fields. In fact, it does exactly what we want.

If there are fewer initializers in a brace-enclosed list than there are elements or members of an aggregate, or fewer characters in a string literal used to initialize an array of known size than there are elements in the array, the remainder of the aggregate shall be initialized implicitly the same as objects that have static storage duration.

The language is a little convoluted but “objects that have static storage duration” are initialized to zero so our unlisted padding field will be zeroed as well. Let’s check out the assembly again to be sure.

movq    $0, -16(%rbp)
movl    $2130706433, -16(%rbp)
movw    $80, -12(%rbp)

This isn’t exactly what I was expecting but it makes sense. By writing zero as an 8-byte value over the entire variable each field is initialized to zero. Then the two fields we have explicitly given values to are set as before.

What is the lesson to be learned here? C gives the programmer almost complete control over almost all of the low level details of the system executes their code but this control comes at a price. The programmer must understand how the low level details work or else code which, at a high level, seems to be correct may not do what they intend.

After fighting with TweetDeck to post a picture: Why can’t I drag-and-drop it into the compose widget? Why must I manually resize it so that it’s under 3MB? I decided it might be time to choose a better Twitter client. This brings me around to TweetBot.

As far as I can tell TweetBot is the best Twitter client available for OS X. It supports the feature for which I use TweetDeck over Twitter’s offical client: multiple columns. The one sticking point for me is the price. Compared to every other Twitter app I’ve used, which were free, TweetBot costs infinitely more: $19.99. In the grand scheme of my budget though $20 isn’t very much but I tend to give a reasonable amount of thought to non-food items that cost more than a few dollars so here are some things I compared it to:

• Dinner out at a restaurant can easily approach or exceed $20 including tax, tip, beverages and appetizers.
• If I’d bought TweetBot when I first started using Twitter I would have paid, on average, half a cent for each of my 3,875 tweets.
• Based on download size TweetBot is $3.77 per MB, compared to $0.34 per MB for one of my employer’s products.
• A new release on iTunes is also usually around $19.99. In comparison I will probably spend more than 120 minutes paying attention to TweetBot.

I could keep going like this but the comparisons would begin to get silly. In the end I’m going to buy TweetBot. I think the point of this story is that it’s pretty hard to decide on the value of a software program. App stores these days tend to sell things for either free, cheap (1¢ — $2) or expensive (more than $2) compared to old-fashioned boxed software which I recall usually started at $20 and sometimes made it to the bargain bin at $5 — $15. On top of this, if I pay $19.99 for TweetBot now they will never get another cent from me because the Mac App Store doesn’t (currently) charge for updates. Heck, Apple released OS X Mavericks, the product of tens of thousands of man-hours of work (at least), for no cost what-so-ever.

With all of this in mind all I can say is that I have no idea how much software is really worth.