Table of Contents for

21st Century C

As in Example 6-2, copying the contents of a structure is a one-line operation.

#include <assert.h>

typedef struct{
    int a, b;
    double c, d;
    int *efg;
} demo_s;

int main(){
    demo_s d1 = {.b=1, .c=2, .d=3, .efg=(int[]){4,5,6}};
    demo_s d2 = d1;

    d1.b=14;            
    d1.c=41;
    d1.efg[0]=7;

    assert(d2.a==0);    
    assert(d2.b==1);
    assert(d2.c==2);
    assert(d2.d==3);
    assert(d2.efg[0]==7);
}

As before, you should always know whether your assignment is a copy of the data or a new alias, so which is it here? We changed d1.b, and d1.c and d2 didn’t change, so this is a copy. But a copy of a pointer still points to the original data, so when we change d1.efg[0], the change also affects the copy of a pointer d2.efg. This advises that if you need a deep copy where pointer contents are copied, you will need a struct copying function, and if you don’t have any pointers to trace through, then a copy function is overkill and an equals sign will do.

For arrays, the equals sign will copy an alias, not the data itself. In Example 6-3, let’s try the same test of making a copy, changing the original, and checking the copy’s value.

#include <assert.h>

int main(){
    int abc[] = {0, 1, 2};
    int *copy = abc;

    copy[0] = 3;
    assert(abc[0]==3); 
}

Example 6-4 is a slow buildup to a train wreck. It is mostly two functions that automatically allocate two blocks: the first allocates a struct and the second allocates a short array. Being automatic memory, we know that at the end of each function, the respective blobs of memory will be freed.

A function that ends in return x will return the value of x to the calling function (C99 & C11 §6.8.6.4(3)). Seems simple enough, but that value has to be copied out to the calling function, whose frame is about to be destroyed. As previously, for a struct, a number, or even a pointer, the calling function will get a copy of the returned value; for an array, the calling function will get a pointer to the array, not a copy of the data in the array.

That last one is a nasty trap, because the pointer returned may be pointing to an automatically allocated array of data, which is destroyed on function exit. A pointer to a block of memory that has already been automatically freed is worse than useless.

#include <stdio.h>

typedef struct powers {
    double base, square, cube;
} powers;

powers get_power(double in){
    powers out = {.base   = in,                                  
                  .square = in*in,
                  .cube   = in*in*in};
    return out;                                                  
}

int *get_even(int count){
    int out[count];
    for (int i=0; i< count; i++)
        out[i] = 2*i;
    return out;   //bad.                                         
}

int main(){
    powers threes = get_power(3);
    int *evens = get_even(3);
    printf("threes: %g\t%g\t%g\n", threes.base, threes.square, threes.cube);
    printf("evens: %i\t%i\t%i\n", evens[0], evens[1], evens[2]); 
}

If you need a copy of an array, you can still do it on one line, but we’re back to memory-twiddling syntax, as in Example 6-5.

#include <assert.h>
#include <string.h> //memmove

int main(){
    int abc[] = {0, 1, 2};
    int *copy1, copy2[3];

    copy1 = abc;
    memmove(copy2, abc, sizeof(int)*3);

    abc[0] = 3;
    assert(copy1[0]==3);
    assert(copy2[0]==0);
}

Now for the memory part, in which we deal with addresses in memory directly. These will often be allocated manually via malloc.

The easiest way to avoid bugs related to malloc is not to use malloc. Historically (in the 1980s and 1990s), we needed malloc for all sorts of string manipulations; Chapter 9 gives full coverage of strings without using malloc once. We needed malloc to deal with arrays for which length had to be set at runtime, which is pretty common; as per Let Declarations Flow, that is also obsolete.

Here is my roughly comprehensive list of reasons left for using malloc:

I wrote this list to show you that it’s not all that long—and item 5 is a rarity, and item 4 is often a special case of item 3, because giant data sets tend to get put into object-like data structures. Production code tends to have few uses of malloc, typically wrapped in new/copy/free functions so the main code doesn’t have to deal further with memory management.

OK, so we’re clear that pointers and memory allocation are separate concepts, but dealing with pointers themselves can still be a problem, because, well, all those stars are just confusing.

The ostensible rationale for the pointer declaration syntax is that the use and the declaration look alike. What they mean by this is that when you declare:

int *i;

*i is an integer, so it’s only natural that we’d declare that *i is an integer via int *i.

So that’s all well and good, and if it helps you, then great. I’m not sure if I could invent a less ambiguous way of doing it.

Here’s a common design rule, espoused throughout The Design of Everyday Things, for example: things that have drastically different functions should not look similar [Norman 2002]. That book gives the example of airplane controls, where two identical-looking levers often do entirely different things. In a crisis situation, that’s an invitation for human error.

Here, C syntax crashes and burns, because *i in a declaration and *i outside of a declaration do very different things. For example:

int *i = malloc(sizeof(int)); //right
*i = 23;                      //right
int *i = 23;                  //wrong

I’ve thrown the rule that declaration looks like usage out of my brain. Here’s the rule I use, which has served me well: when used for a declaration, a star indicates a pointer; when not used as a declaration, a star indicates the value of the pointer.

Here is a valid snippet:

int i = 13;
int *j = &i;
int *k = j;
*j = 12;

Using the rule given, you can see that on the second line, the initialization is correct, because *j is a declaration, and so a pointer. On the third line, *k is also the declaration of a pointer, so it makes sense to assign to it j, also a pointer. On the last line, *j is not in a declaration, so it indicates a plain integer, and so we can assign 12 to it (and i will change as a result).

So there’s your first tip: bear in mind that when you see *i on a declaration line, it is a pointer to something; when you see *i on a nondeclaration line, it is the pointed-to value.

After some pointer arithmetic, I’ll come back with another tip for dealing with weird pointer declaration syntax.

An element of an array can be expressed as being at some offset from the base of the array. You could declare a pointer double *p; then that’s your base, and you can use the offsets from that base as an array: at the base itself, you will find the contents of the first element, p[0]; go one step from the base and you have the contents of the second, p[1]; et cetera. So if you give me a pointer and the distance from one element to the next, I’ve got an array.

You could just write the base plus offset directly and literally, via a form like (p+1). As your textbooks will tell you, p[1] is exactly equivalent to *(p+1), which explains why the first element in an array is p[0] == *(p+0). K & R spend about six pages on this stuff [2nd ed. sections 5.4 and 5.5].

The theory implies a few rules for notating arrays and their elements in practice:

Example 6-6 shows some of these rules in use.

#include <stdio.h>

int main(){
    int evens[5] = {0, 2, 4, 6, 8};
    printf("The first even number is, of course, %i\n", *evens);         
    int *positive_evens = &evens[1];                                     
    printf("The first positive even number is %i\n", positive_evens[0]); 
}

I’ll throw in one nice trick, based on the pointer arithmetic rule that p+1 is the address of the next point in an array—&p[1]. With this rule, you don’t need an index for for loops that step through an array. Example 6-7 uses a spare pointer that starts at the head of a list, and then steps through the array with p++ until it hits the NULL marker at the end. The next pointer declaration tip will make this much more legible.

#include <stdio.h>

int main(){
    char *list[] = {"first", "second", "third", NULL};
    for (char **p=list; *p != NULL; p++){
        printf("%s\n", p[0]);
    }
}

Base-plus-offset thinking doesn’t give us much payoff in terms of cute syntactic tricks, but it does explain a lot about how C works. In fact, consider the struct. Given:

typedef struct{
    int a, b;
    double c, d;
} abcd_s;

abcd_s list[3];

As a mental model, you can think of list as our base, and list[0].b is just far enough past that to refer to b. That is, given that the location of list is the integer (size_t)&list, b is located at (size_t)&list + sizeof(int); and so list[2].d would be at the position (size_t)&list + 6*sizeof(int) + 5*sizeof(double). Under this thinking, a struct is much like an array, except the elements have names instead of numbers and are of different types and sizes.

It’s not quite correct, because of alignment: the system may decide that the data needs to be in chunks of a certain size, so fields may have extra space at the end so that the next field begins at the right point, and the struct may have padding at its end so that a list of structs is appropriately aligned [C99 & C11 §6.7.2.1(15) and (17)]. The header stddef.h defines the offsetof macro, which makes the base-plus-offset thinking accurate again: list[2].d really is at (size_t)&list + 2*sizeof(abcd_s) + offsetof(abcd_s, d).

By the way, there can’t be padding at the beginning of a struct, so list[2].a is at (size_t)&list+ 2*sizeof(abcd_s).

Here is a silly function to recursively count the number of elements in a list until we hit a zero-valued element. Let us say (and this is a bad idea) that we’d like to be able to use this function for any type of list where a zero value makes sense, so it will take in a void pointer.

int f(void *in){
    if (*(int*)in==0) return 1;
    else return 1 + f(&(in[1]));  //This won't work.
}

The base-plus-offset rule explains why this won’t work. To refer to a_list[1], the compiler needs to know the exact length of a_list[0], so it knows how far to offset from the base. But without a type attached, it can’t calculate that size.

typedef char* string;

#include <stdio.h>
typedef char* string;

int main(){
    string list[] = {"first", "second", "third", NULL};
    for (string *p=list; *p != NULL; p++){
        printf("%s\n", *p);
    }
}

double a_fn(int, int); //a declaration

double (*a_fn_type)(int, int);   //a type: pointer-to-function

typedef double (*a_fn_type)(int, int); //a typedef for a pointer to function

double apply_a_fn(a_fn_type f, int first_in, int second_in){
    return f(first_in, second_in);
}