那些你从不想知道的 C 语言冷知识

#Original (English)

Source: https://www.mikeash.com/pyblog/friday-qa-2012-08-24-things-you-never-wanted-to-know-about-c.html

It’s been a bit since I did an article, but I’m back again, with a somewhat off-the-cuff treatment of a very twisted set of code I use to pretend that C has exceptions. I delve into little-known extensions of C, Linux compatibility, and worst of all, goto, so be warned!

Error handling in CC, being something of a bare-metal language by today’s standards, lacks any advanced facilities for managing control flow when errors happen. Most platforms have found their own ways of coping with the situation, some with language features, some with framework conventions, and others by not coping at all.

ExceptionsThe best known, and also perhaps most debated, means of handling control flow for error conditions is exceptions. C++, Java, Objective-C, PHP, and many others all have some form of exception handling construct. In Objective-C, exceptions look like this:

1
    @try {
2
        if (![someObject doSomethingInteresting]) {
3
            @throw [NSException exceptionWithName:NSInternalInconsistencyException reason:@"Failed to frobulate the glockenspiel!" userInfo:nil];
4
        }
5
        return YES;
6
    } @catch (NSException *exception) {
7
        NSLog(@"Either die in the vacuum of space, or tell me what you thought of my poem.");
8
        return NO;
9
    } @finally {
10
        [prognosticator cleanupAfterSlithyToves];
11
    }

Fortunately, Apple realized how ridiculous this tends to look in Cocoa and deprecated exceptions for error handling, instead opting for the NSError model. The use of exception handling in Objective-C is now reserved (at least in theory) for truly “exceptional” conditions, particularly programmer error.

C does have a primitive sort of exception handling in the setjmp/longjmp functions. However, they’re extremely weird, not very full featured, and highly error-prone, so they make a poor choice.

Historically, exceptions in Objective-C were implemented with these functions, but Apple quite sensibly replaced the unwieldy macros with a compiler feature which calls into the C++ exception implementation. In essence, @try in Objective-C and try in C++ are now the same thing, though they’re still not interchangeable due to the separation of class heirarchies.

Grafting exceptions onto CThe first question asked is why anyone would want to put exceptions into pure C. My answer is that this code is just too ugly to let live:

1
    struct whatever *make_a_whatever(int alpha, const char *beta, const char *gamma, size_t delta)
2
    {
3
        struct whatever *brillig = malloc(sizeof(struct whatever));
4
        int fd = -1, r = 0;
5

6
        if (!brillig)
7
            return NULL;
8
        brillig->alpha = alpha;
9
        brillig->beta = strdup(beta);
10
        if (!brillig->beta) {
11
            free(brillig);
12
            return NULL;
13
        }
14
        if ((fd = open(gamma, O_RDONLY)) == -1) {
15
            free(brillig->beta);
16
            free(brillig);
17
            return NULL;
18
        }
19
        brillig->gamma = malloc(delta);
20
        if (!brillig->gamma) {
21
            close(fd);
22
            free(brillig->beta);
23
            free(brillig);
24
            return NULL;
25
        }
26
        if ((r = read(fd, brillig, delta)) != delta) {
27
            close(fd);
28
            free(brillig->gamma);
29
            free(brillig->beta);
30
            free(brillig);
31
            return NULL;
32
        }
33
        close(fd);
34
        return brillig;
35
    }

Admittedly, the example is contrived and could be reorganized to require less repetition, but in the real world I’ve ended up with code that looks a lot like this. One possible solution is a dumb goto:

1
    struct whatever *make_a_whatever(int alpha, const char *beta, const char *gamma, size_t delta)
2
    {
3
        struct whatever *brillig = malloc(sizeof(struct whatever));
4
        int fd = -1, r = 0;
5

6
        if (!brillig) goto error;
7
        brillig->alpha = alpha;
8
        if (!(brillig->beta = strdup(beta))) goto error;
9
        if ((fd = open(gamma, O_RDONLY)) == -1) goto error;
10
        if (!(brillig->gamma = malloc(delta))) goto error;
11
        if ((r = read(fd, brillig, delta)) != delta) goto error;
12
        close(fd);
13
        return brillig;
14
    error:
15
        if (fd != -1) close(fd);
16
        if (brillig) {
17
            free(brillig->gamma);
18
            free(brillig->beta);
19
            free(brillig);
20
        }
21
        return NULL;
22
    }

This is certainly better, but still litters the code with a nest of tightly clustered if branches. The next step to readability is to macroize the branches:

1
    #define error_if(c)     do { if (!(c)) goto error; }
2
    #define error_ifnull(p) do { if ((p) == NULL) goto error; }
3
    #define error_ifneg1(e) do { if ((e) == -1) goto error; }
4

5
    struct whatever *make_a_whatever(int alpha, const char *beta, const char *gamma, size_t delta)
6
    {
7
        struct whatever *brillig = malloc(sizeof(struct whatever));
8
        int fd = -1;
9

10
        error_ifnull(brillig);
11
        brillig->alpha = alpha;
12
        error_ifnull(brillig->beta = strdup(beta));
13
        error_ifneg1(fd = open(gamma, O_RDONLY));
14
        error_ifnull(brillig->gamma = malloc(delta));
15
        error_if(read(fd, brillig, delta) == delta);
16
        close(fd);
17
        return brillig;
18
    error:
19
        if (fd != -1) close(fd);
20
        if (brillig) {
21
            free(brillig->gamma);
22
            free(brillig->beta);
23
            free(brillig);
24
        }
25
        return NULL;
26
    }

Now, what if you want to know what went wrong? You have no exceptions to pass information up the call stack, nor any place to stuff an error message besides printing to stderr, which may not be appropriate for an internal function. What if you have significant cleanup that has to be done regardless of whether or not errors occurred? What if you want to be able to return early from the function but have your cleanup code still run?

The Solution: Preprocessor Abuse 101For the sake of brevity, I’ll skip a few steps in the process that leads to the solution I came up with for these problems and just show it. I needed error handling that:

• Can be applied easily to any function

• Can pass information about specific errors up the call chain

• Can run cleanup code regardless of whether an error ocurrred

• Can run cleanup code regardless of whether the function returns early

• Can be used with both Clang and GCC

That last is a doozy. One might imagine blocks as a fairly simple solution to several of these issues at once, but blocks don’t exist in GCC outside of Apple’s obsolete customized version.

First, here is what our make_a_whatever function looks like with the error handling I wrote:

1
    struct whatever *make_a_whatever(int alpha, const char *beta, const char *gamma, size_t delta, error_t **error)
2
    {
3
        struct whatever *brillig = NULL:
4
        int fd = -1;
5

6
        error_enter() {
7
            on_nullerror(brillig = malloc(sizeof(struct whatever)), ENOMEM, "can't allocate our brillig!");
8
            brillig->alpha = alpha;
9
            on_nullerror(brillig->beta = strdup(beta), ENOMEM, "can't allocate beta for brilling with alpha %d!", alpha);
10
            on_errno(fd = open(gamma, O_RDONLY), "can't open gamma %s!", gamma);
11
            on_nullerror(brillig->gamma = malloc(delta), ENOMEM, "can't allocate gamma either!");
12
            on_readerr(fd, brillig, delta, "delta's not in gamma!");
13
            return brillig;
14
        } error_handler() {
15
            if (brillig) {
16
                free(brillig->gamma);
17
                free(brillig->beta);
18
                free(brillig);
19
            }
20
            return NULL;
21
        } error_finally() {
22
            if (fd != -1)
23
                close(fd);
24
        } error_exit(error);
25
    }

Whether or not you find this more readable is a matter of opinion, of course, but it’s certainly more functional. For any given error, a formatted message is available, and the error is returned by reference if and only if one occurred. Here’s an example call:

1
    error_t *error = NULL;
2
    struct whatever *whatever = make_a_whatever(1, "gyre", "gimble", SIZE_WABE, &error);
3

4
    if (!whatever)
5
        error_write(error, STDERR_FILENO, true);

For convenience, the error_write function can optionally free the error_t object (this is the third parameter).

There’s a good bit of magic behind these macros and functions. Here they are in order of appearance:

error_enterPrepare yourself:

1
    #define error_enter()   do {    \
2
        __label__ _error_start, _error_exit, _error_finally, _error_done;   \
3
        __block error_t *_last_error = NULL;    \
4
        do {    \
5
            CLEANUP_DECL    \
6
        _error_start:;

Yuck, huh?

First, the entry macro declares several “local” labels. A local label is simply a label whose name is local to its enclosing scope. This is a GCC extension supported by Clang. These four labels are used by the rest of the macros to manage the function’s control flow. Notice that because the labels are used across multiple macros, error handling scopes can not be nested.

Next, an error_t is declared to hold any error that occurs within this error handling scope. It is marked __block, as the Clang implementation of the “finally” clause uses blocks and must update this variable from inside one. For the GCC build, __block is #defined to nothing.

Next, the “cleanup declaration” takes place, then the “start” label is marked. The main function body goes underneath this.

CLEANUP_DECL and friendsThe cleanup delcaration and several other pieces of the cleanup implementation are macros, as the implementation is significantly different between GCC and Clang:

1
    #ifndef __has_feature
2
    #define __has_feature(f) 0
3
    #endif
4

5
    #if __has_feature(blocks)
6
    typedef void (^_error_cleanup_block_t)(void);
7
    static inline void _error_cleanup_block(_error_cleanup_block_t *b) { (*b)(); }
8
    #define CLEANUP_DECL _error_cleanup_block_t _error_cleanup __attribute__((cleanup(_error_cleanup_block),unused)) = NULL;    \
9
                         goto _error_finally;
10
    #define CLEANUP_ASSIGN _error_cleanup = ^
11
    #define CLEANUP_DONE_ASSIGN goto _error_start
12
    #elif __GNUC__
13
    #define __block
14
    typedef void (*_error_cleanup_func_t)(void);
15
    #define CLEANUP_DECL auto void _error_cleanup_f(_error_cleanup_func_t *f);  \
16
                         void (*_error_cleanup)(void) __attribute__((cleanup(_error_cleanup_f),unused)) = NULL;
17
    #define CLEANUP_ASSIGN  void _error_cleanup_f(_error_cleanup_func_t *f)
18
    #define CLEANUP_DONE_ASSIGN
19
    #endif

For Clang (and any potential future GCC which adopts blocks), a typedef is declared for a cleanup block, just your basic takes-and-returns-void. A static inline C function is defined (in the header, remember, not as part of the macro expansion) for running the block.

The cleanup delcaration for Clang declares an _error_cleanup_block_t with the cleanup attribute. This attribute (another extension originally from GCC) says “run this C function when this variable goes out of scope”. It is also marked unused to avoid warnings when -Wunused-variable is turned on. Next, it jumps to the “finally” label, before the function’s main body runs. As we’ll see later, this is necessary to make sure the cleanup block is properly set up before any potential return from the function.

For GCC, which has no blocks, a similar process takes place, but __block is defined to nothing, and instead of declaring a cleanup block, the code declares a “nested function” to serve for cleanup.

Nested functions are a GCC-only extension which Clang refused to adopt as being not worth the trouble when blocks provide a much better solution for scope-specific functions. The nested function exists only within its parent function and has the same ability to capture from the lexical scope of the parent that a block does. As a nested function can not be used outside its parent function, unlike blocks, it has no need for a special qualifier to specify the memory management around captured variables.

Lastly, the GCC version does not jump to the “finally” label, as the nested function does not need to be assigned anywhere to work; the prototype is enough to use it.

The auto keyword, otherwise pretty much useless in C, marks the delcaration as the prototype for a nested function, rather than as a standard function prototype. This is a nonstandard use of a standard keyword and yet another GCC extension.

on_everythingFor the sake of brevity, again, I will not paste every single one of the on_*() macros here, as they’re all largely the same.

1
    // Common macros, do not call directly
2
    #if DEBUG
3
    #define _error_fail(e, msg, ...)    do {    \
4
        _last_error = error_newf(e, __LINE__, __FILE__, __PRETTY_FUNCTION__, msg, ## __VA_ARGS__);  \
5
        goto _error_exit;   \
6
    } while (0)
7
    #else
8
    #define _error_fail(e, msg, ...)    do {    \
9
        _last_error = error_newf(e, msg, ## __VA_ARGS__);   \
10
        goto _error_exit;   \
11
    } while (0)
12
    #endif
13
    #define _error_throw() do { goto _error_exit; } while (0)
14

15
    // Use e as the error code when (e) < 0.
16
    // Intended for POSIX routines that return an error code, such as pthread_*()
17
    #define on_error(e, msg, ...)       do {    \
18
        int _error_code __attribute__((unused)) = (e);  \
19
        if (_error_code < 0)    \
20
            _error_fail(_error_code, msg, ## __VA_ARGS__);  \
21
    } while (0)
22

23
    // Re-throw an error when (e) == false.
24
    // Intended for chaining error-returning methods.
25
    #define on_falsethrow(e) do { if (!(e)) _error_throw(); } while (0)

Each on_*() macro checks its own particular condition for an error, saves off any relevant error code for use by the formatting function, and calls the _error_fail() macro.

In turn, the _error_fail() macro sets the _last_error variable to a new error_t based on the passed error code, message, and in debug mode, the file, line, and function in which the error occurred. It then jumps to _error_exit, which takes it to the “catch” handler (see below).

The “throw” versions of these macros are intended for passing errors up the call chain; the existing error_t object is simply left as is and the “catch” handler is invoked directly. For example:

1
    bool make_many_whatevers(size_t n, struct whatever **list, error_t **error)
2
    {
3
        struct whatever *mimsy = NULL;
4
        size_t i = 0;
5

6
        error_enter() {
7
            for (i = 0; i < n; ++i) {
8
                on_nullthrow(mimsy = make_a_whatever(/* etc */, error));
9
            }
10
            return true;
11
        } error_handler() {
12
            for (size_t j = 0; j < i; ++j)
13
                free_a_whatever(list[i]);
14
            return false;
15
        } error_finally() {
16
        } error_exit(error);
17
    }

The caller will receive whatever the underlying error was.

error_handlerAnd now the “catch” block:

1
    #define error_handler() \
2
            goto _error_done;   \
3
        _error_exit: __attribute__((unused));

The error_handler() macro comes immediately before the “something went wrong” part of the function. Immediately after the main body of the function, it jumps to the “done” label. This is the “normal exit” from function case, making the main body look like this:

1
    _error_start:
2
        // main body
3
        goto _error_done;
4
    _error_exit:
5
        // something went wrong

The error_exit label is declared unused so that the compiler doesn’t complain if the function has no on*() statements, which could happen if you’re future-proofing a routine for adding error handling later but haven’t gotten there yet. This is where the “catch” code goes, handling any errors.

error_finallyAnd finally, the “finally”:

1
    #define error_finally() \
2
            goto _error_done;   \
3
        _error_finally:;    \
4
            CLEANUP_ASSIGN {

This is where the fun happens. The “finally” part, coming after the “catch”, jumps to “done” at the end of it. Notice that this means the “finally” code is never directly executed in normal control flow! In fact, in the GCC version, the lines under _error_finally are never executed at all.

CLEANUP_ASSIGN in Clang takes the _error_cleanup block that was declared in CLEANUP_DECL and actually assigns the “finally” code to it. Hence, any variables whose values need to be modified by the “finally” handler must be declared __block. This is why, as we saw above, the “start” jumps to here before actually executing the function’s main body; if the block wasn’t assigned at that time, no cleanup would ever be executed.

The GCC version simply starts the nested function which was declared earlier. In either case, the “finally” code ends up as part of a function which is not part of the normal control flow, and will be executed by the cleanup attribute on the _error_cleanup variable. Notice that the GCC version never bothers assigning any value to that variable, since the nested function will simply be called by name instead of jumped to by value as a block would be.

error_exitTime to clean up after ourselves:

1
    #define error_exit(error_param) \
2
                if (_last_error && error_param) \
3
                    *error_param = _last_error; \
4
            };  \
5
            CLEANUP_DONE_ASSIGN;    \
6
        _error_done:;   \
7
        } while (0);    \
8
    } while (0)

As part of the “finally” block, the error parameter which was passed to this macro, if non-NULL, is given the value of _last_error, if any. The “finally” block is ended, and under Clang, control jumps back to the “start”, continuing the main body of the function. (Again, under GCC the extra bit of control-flow trickery doesn’t need to happen.)

The “done” label, which marks the final end of all this mess, shows up here, and the error handler scope is closed out.

So, here are the steps in execution order:

• Declare an error variable and a cleanup block.

• In Clang only, jump to the “finally” handler to assign the code to the cleanup block.

• In Clang only, jump back to the function’s main body.

• On error only, assign the error variable, and run the error handler.

• Execute the “finally” handler.

• Update any error parameter.

The error_*() functionsThere’s one group of code we haven’t looked at yet: The functions which actually manage the error_t type. They’re pretty straightforward; there’s no hackery involved in this part. Well, maybe just a little to cover the differences between the debug and non-debug cases and grab the executable’s name:

1
    typedef struct {
2
        int error_code;
3
        char *message;
4
    #if DEBUG
5
        int line;
6
        char *file;
7
        char *function;
8
    #endif
9
    } error_t;
10

11
    #if DEBUG
12
    #define DEBUG_PARMS , int line, const char *file, const char *function
13
    #define DEBUG_PASS(f) , line, f(file), f(function)
14
    #define DEBUG_FNUM 5
15
    #define DEBUG_VNUM 6
16
    #else
17
    #define DEBUG_PARMS
18
    #define DEBUG_PASS(f)
19
    #define DEBUG_FNUM 2
20
    #define DEBUG_VNUM 3
21
    #endif
22

23
    static inline error_t __attribute__((malloc)) *error_new(int error_code DEBUG_PARMS, char *message)
24
    {
25
        error_t *r = calloc(1, sizeof(error_t));
26

27
        *r = (error_t){ error_code, strdup(message) DEBUG_PASS(strdup) };
28
        return r;
29
    }
30

31
    static inline error_t __attribute__((format(printf,DEBUG_FNUM,0),malloc)) *error_newvf(int error_code DEBUG_PARMS,
32
                                                                                           char *format, va_list args)
33
    {
34
        error_t *r = calloc(1, sizeof(error_t));
35

36
        *r = (error_t){ error_code, NULL DEBUG_PASS(strdup) };
37
        if (vasprintf(&r->message, format, args) < 0)
38
            r->message = strdup(format);
39
        return r;
40
    }
41

42
    static inline error_t __attribute__((format(printf,DEBUG_FNUM,DEBUG_VNUM),malloc)) *error_newf(
43
        int error_code DEBUG_PARMS, char *format, ...)
44
    {
45
        error_t *r = NULL;
46
        va_list args;
47

48
        va_start(args, format);
49
        r = error_newvf(error_code DEBUG_PASS(), format, args);
50
        va_end(args);
51
        return r;
52
    }
53

54
    static inline void error_free(error_t *error)
55
    {
56
    #if DEBUG
57
        free(error->function);
58
        free(error->file);
59
    #endif
60
        free(error->message);
61
        free(error);
62
    }
63

64
    static inline void error_write(error_t *error, int fd, bool do_free)
65
    {
66
    #ifdef MACOSX
67
        extern char **_NSGetProgname(void);
68
        char *progname = *_NSGetProgname();
69
    #elif defined(LINUX)
70
        char buf[MAXPATHLEN + 1] = {0}, *progname = buf;
71
        if (readlink("/proc/self/exe", buf, MAXPATHLEN) < 0)
72
            progname = "unknown";
73
    #endif
74
    #if DEBUG
75
        dprintf(fd, "%s: %s (in %s at %s:%d)\n", basename(progname), error->message, error->function, error->file, error->line);
76
    #else
77
        dprintf(fd, "%s: %s\n", basename(progname), error->message);
78
    #endif
79
        if (do_free)
80
            error_free(error);
81
    }

The only really interesting part of this code is the part in error_write() which grabs the executable’s name. Since it’s not assumed that argv is available directly, some platform-specific code is invoked. On OS X, the _NSGetProgname() function from crt_externs.h is used, whereas on Linux, the contents of /proc/self/exe symlink are read. dprintf() is just fprintf() that takes a descriptor instead of a FILE *.

For the curious, attribute((malloc)) marks the function as returning a pointer that is guaranteed not to be aliased by any other pointers, which is useful for optimization purposes. attribute((format(printf,n,m))) simply tells the compiler to do the same checking of the format string and arguments that it would do for the printf() family of functions. These and the other attributes are documented in the GCC Manual.

ConclusionThis error handling trick takes a hybrid exception/error-object approach to the problem, and comes with a laundry list of drawbacks:

• Relies heavily on lots of compiler-specific language extensions which are definitely not universally portable

• Requires all modified variables in “finally” handlers to use __block, a qualifier which makes no sense to anyone looking at the code on Linux

• Severely abuses the preprocessor, making the actual functionality of the code obscure to a newcomer

• Severely abuses goto, resulting in a non-linear and unobvious control flow.

• Any variable that needs to be available in more than one of the blocks of the function must be declared outside the error handler scope

• Empty “catch” or “finally” handlers can’t be ommitted

• Error handling scopes can’t be nested

• The macros are somewhat poorly named in this implementation

• Passing the error_t object around is cumbersome unless you’re used to the NSError style of error handling

• Probably isn’t thread-safe (I haven’t tested this)

• Doesn’t emulate either exceptions or error objects perfectly, meaning experience from neither can be fully applied

• Is in no way superior to simply using C++‘s exceptions unless you have an aversion to, or are unable to use, C++

This code is hastily designed, organically grown, has obvious inefficiencies, and is definitely not useful in a production environment in this form. Mostly, it’s just a cool way of playing with the language. Still, it shows just how much a determined (and perhaps slightly unbalanced) mind can do with relatively crummy tools.

For some even more extreme examples of doing strange and unbelievable things in both C and Objective-C, I recommend looking into Justin Spahr-Summers’ libextc and libextobjc libraries, which served as partial inspiration for the code I presented here. Both contain some of the most amazing and arcane uses of macros, switch, if, for, and Duff’s Device that I’ve ever encountered outside of the IOCCC. To top it off, libextc manages to do all of its work while being completely platform- and compiler-agnostic, which is a true accomplishment.

That’s about all for this week. Stay tuned for Mike’s next article, coming to you a week from today. Thanks for reading!