Table of Contents for

21st Century C

The token reserved for the preprocessor is the octothorp, #, and the preprocessor makes three entirely different uses of it.

You know that a preprocessor directive like #define begins with a # at the head of the line. Whitespace before the # is ignored (K&R 2nd ed. §A12, p. 228), so here’s your first tip: you can put throwaway macros in the middle of a function, just before they get used, and indent them to flow with the function. According to the old school, putting the macro right where it gets used is against the “correct” organization of a program (which puts all macros at the head of the file), but having it right there makes it easy to refer to and makes the throwaway nature of the macro evident. The preprocessor knows next to nothing of where functions begin and end, so the scope of a macro is from its occurrence in the file to the end of the file.

The next use of the # is in a macro: it turns input code into a string. Example 8-2 shows a program demonstrating a point about the use of sizeof (see the sidebar), though the main focus is on the use of the preprocessor macro.

#include <stdio.h>

#define Peval(cmd) printf(#cmd ": %g\n", cmd);

int main(){
    double *plist = (double[]){1, 2, 3};        
    double list[] = {1, 2, 3};
    Peval(sizeof(plist)/(sizeof(double)+0.0));
    Peval(sizeof(list)/(sizeof(double)+0.0));
}

When you try it, you’ll see that the input to the macro is printed as plain text, and then its value is printed, because #cmd is equivalent to cmd as a string. So Peval(list[0]) would expand to:

printf("list[0]" ": %g\n", list[0]);

Does that look malformed to you, with the two strings "list[0]" ": %g\n" next to each other? The next preprocessor trick is if two literal strings are adjacent, the preprocessor merges them into one: "list[0]: %g\n". And this isn’t just in macros:

printf("You can use the preprocessor's string "
       "concatenation to break long lines of text "
       "in your program. I think this is easier than "
       "using backslashes, but be careful with spacing.");

//This is not reliable:
#define arraysize(list) sizeof(list)/sizeof(list[0])

Conversely, you might want to join together two things that are not strings. Here, use two octothorps, which I herein dub the hexadecathorp: ##. If the value of name is LL, then when you see name ## _list, read it as LL_list, which is a valid and usable variable name.

Gee, you comment, I sure wish every array had an auxiliary variable that gave its length. OK, Example 8-3 writes a macro that declares a local variable ending in _len for each list you tell it to care about. It’ll even make sure every list has a terminating marker, so you don’t even need the length.

That is, this macro is total overkill, and I don’t recommend it for immediate use, but it does demonstrate how you can generate lots of little temp variables that follow a naming pattern that you choose.

#include <stdio.h>
#include <math.h> //NAN

#define Setup_list(name, ...)                               \
    double *name ## _list = (double []){__VA_ARGS__, NAN};  \ 
    int name ## _len = 0;                                   \
    for (name ## _len =0;                                   \
            !isnan(name ## _list[name ## _len]);            \
            ) name ## _len ++;


int main(){
    Setup_list(items, 1, 2, 4, 8);                           
    double sum=0;
    for (double *ptr= items_list; !isnan(*ptr); ptr++)       
        sum += *ptr;
    printf("total for items list: %g\n", sum);

    #define Length(in) in ## _len                            

    sum=0;
    Setup_list(next_set, -1, 2.2, 4.8, 0.1);
    for (int i=0; i < Length(next_set); i++)                 
        sum += next_set_list[i];
    printf("total for next set list: %g\n", sum);
}

As a stylistic aside, there has historically been a custom to indicate that a function is actually a macro by putting it in all caps, as a warning to be careful to watch for the surprises associated with text substitution. I think this looks like yelling, and prefer to mark macros by capitalizing the first letter. Others don’t bother with the capitalization thing at all.

The extern keyword is a simpler issue than static, because it is only about linkage, not memory models. The typical setup for a variable with external linkage:

That’s all you have to do to use variables with external linkage.

You may be tempted to put the extern declaration not in a header, but just as a loose declaration in your code. In file1.c, you have declared int x, and you realize that you need access to x in file2.c, so you throw a quick extern int x at the top of the file. This will work—today. Next month, when you change file1.c to declare double x, the compiler’s type checking will still find file2.c to be entirely internally consistent. The linker blithely points the routine in file2.c to the location where the double named x is stored, and the routine blithely misreads the data there as an int. You can avoid this disaster by leaving all extern declarations in a header to #include in both file1.c and file2.c. If any types change anywhere, the compiler will then be able to catch the inconsistency.

Under the hood, the system is doing a lot of work to make it easy for you to declare one variable several times wile allocating memory for it only once. Formally, a declaration marked as extern is a declaration (a statement of type information so the compiler can do consistency checking), and not a definition (instructions to allocate and initialize space in memory). But a declaration without the extern keyword is a tentative definition: if the compiler gets to the end of the unit (defined below) and doesn’t see a definition, then the tentative definitions get turned into a single definition, with the usual initialization to zero or NULL. The standard defines unit in that sentence as a single file, after #includes are all pasted in (a translation unit; see C99 & C11 §6.9.2(2)).

Compilers like gcc and Clang typically read unit to mean the entire program, meaning that a program with several non-extern declarations and no definitions rolls all these tentative definitions up into a single definition. Even with the --pedantic flag, gcc doesn’t care whether you use the extern keyword or leave it off entirely. In practice, that means that the extern keyword is largely optional: your compiler will read a dozen declarations like int x=3 as a single definition of a single variable with external linkage. K&R [2nd ed, p 227] describe this behavior as “usual in UNIX systems and recognized as a common extension by the [ANSI] Standard”. [Harbison 1991] §4.8 documents four distinct interpretations of the rules for externs.

This means that if you want two variables with the same name in two files to be distinct, but you forget the static keyword, your compiler will probably link those variables together as a single variable with external linkage; subtle bugs can easily ensue. So be careful to use static for all file-scope variables intended to have internal linkage.

The trick to reading declarations is to read from right to left. Thus:

You can see that the const always refers to the text to its left, just as the * does.

You can switch a type name and const, and so write either int const or const int (though you can’t do this switch with const and *). I prefer the int const form because it provides consistency with the more complex constructions and the right-to-left rule. There’s a custom to use the const int form, perhaps because it reads more easily in English or because that’s how it’s always been done. Either works.

In practice, you will find that const sometimes creates tension that needs to be resolved, when you have a pointer that is marked const, but want to send it as an input to a function that does not have a const marker in the right place. Maybe the function author thought that the keyword was too much trouble, or believed the chatter about how shorter code is always better code, or just forgot.

Before proceeding, you’ll have to ask yourself if there is any way in which the pointer could change in the const-less function being called. There might be an edge case where something gets changed, or some other odd reason. This is stuff worth knowing anyway.

If you’ve established that the function does not break the promise of const-ness that you made with your pointer, then it is entirely appropriate to cheat and cast your const pointer to a non-const for the sake of quieting the compiler.

//No const in the header this time...
void set_elmt(int *a, int *b){
    a[0] = 3;
}

int main(){
    int a[10];
    int const *b = a;
    set_elmt(a, (int*)b);   //...so add a type-cast to the call.
}

The rule seems reasonable to me. You can override the compiler’s const-checking, as long as you are explicit about it and indicate that you know what you are doing.

If you are worried that the function you are calling won’t fulfill your promise of const-ness, then you can take one step further and make a full copy of the data, not just an alias. Because you don’t want any changes in the variable anyway, you can throw out the copy afterward.

Let us say that we have a struct—name it counter_s—and we have a function that takes in one of these structs, of the form f(counter_s const *in). Can the function modify the elements of the structure?

Let’s try it: Example 8-5 generates a struct with two pointers, and in ratio, that struct becomes const, yet when we send one of the pointers held by the structure to the const-less subfunction, the compiler doesn’t complain.

#include <assert.h>
#include <stdlib.h>  //assert

typedef struct {
    int *counter1, *counter2;
} counter_s;

void check_counter(int *ctr){ assert(*ctr !=0); }

double ratio(counter_s const *in){                   
    check_counter(in->counter2);                     
    return *in->counter1/(*in->counter2+0.0);
}

int main(){
    counter_s cc = {.counter1=malloc(sizeof(int)),   
                   .counter2=malloc(sizeof(int))};
    *cc.counter1 = *cc.counter2 = 1;
    ratio(&cc);
}

In the definition of your struct, you can specify that an element be const, though this is typically more trouble than it is worth. If you really need to protect only the lowest level in your hierarchy of types, your best bet is to put a note in the documentation.

Example 8-6 is a simple program to check whether the user gave Iggy Pop’s name on the command line. Sample usage from the shell (recalling that $? is the return value of the just-run program):

iggy_pop_detector Iggy Pop; echo $?      #prints 1
iggy_pop_detector Chaim Weitz; echo $?   #prints 0

#include <stdbool.h>
#include <strings.h> //strcasecmp

bool check_name(char const **in){  
    return   (!strcasecmp(in[0], "Iggy") && !strcasecmp(in[1], "Pop"))
           ||(!strcasecmp(in[0], "James") && !strcasecmp(in[1], "Osterberg"));
}

int main(int argc, char **argv){
    if (argc < 2) return 0;
    return check_name(&argv[1]);
}

The check_name function takes in a pointer to (string that is constant), because there is no need to modify the input strings. But when you compile it, you’ll find that you get a warning. Clang says: “passing char ** to parameter of type const char ** discards qualifiers in nested pointer types.” In a sequence of pointers, all the compilers I could find will convert to const what you could call the top-level pointer (casting to char * const *), but complain when asked to const-ify what that pointer is pointing to (char const **, aka const char **).

Again, you’ll need to make an explicit cast—replace check_name(&argv[1]) with:

check_name((char const**)&argv[1]);

Why doesn’t this entirely sensible cast happen automatically? We need some creative setup before a problem arises, and the story is inconsistent with the rules to this point. So the explanation is a slog; I will understand if you skip it.

The code in Example 8-7 creates the three links in the diagram: the direct link from constptr -> fixed, and the two steps in the indirect link from constptr -> var and var -> fixed. In the code, you can see that two of the assignments are made explicitly: constptr -> var and constptr -> -> fixed. But because *constptr == var, that second link implicitly creates the var -> fixed link. When we assign *var=30, that assigns fixed = 30.

Example 8-7. We can modify the data via an alternate name, even though it is const via one name—this is deemed to be illegal (constfusion.c)

#include <stdio.h>

int main(){
    int *var;
    int const **constptr = &var; // the line that sets up the failure
    int const fixed = 20;
    *constptr = &fixed;          // 100% valid
    *var = 30;
    printf("x=%i y=%i\n", fixed, *var);
}

We would never allow int *var to point directly at int const fixed. We only managed it via a sleight-of-pointer where var winds up implicitly pointing to fixed without explicitly stating it.

As earlier, data that is marked as const under one name can be modified using a different name. So, really, it’s little surprise that we were able to modify the const data using an alternative name.^[11]

I enumerate this list of problems with const so that you can surmount them. As literature goes, it isn’t all that problematic, and the recommendation that you add const to your function declarations as often as appropriate still stands—don’t just grumble about how the people who came before you didn’t provide the right headers. After all, some day others will use your code, and you don’t want them grumbling about how they can’t use the const keyword because your functions don’t have the right headers.