CODEWITHSUNDEEP
clambdamacros
U. Windl
U. Windl

Reputation: 4325

portability and safety of C macro using lambda parameter

Preface

I know that there are several libraries for auto-testing available. Let's ignore that for this question, please.

Motivation

Implementing some library I got tired of manual testing, so I started to write a "self-test" program, starting with code using many assert()s. Unfortunately when an assert() fails, only limited information is shown on the screen, and I would typically have to use the debugger to examine the core dump to get more details of the failure.

So I added a macro that allows a printf()-like output (implemented via the E() (for error) macro) when an assertion fails; I named that macro VA() (for verbose assertion):

#define VA(assert_cond, msg, ...)   do { \
    if ( !(assert_cond) ) E(msg, ##__VA_ARGS__); \
    assert(assert_cond); \
} while (0)

Using that would look like this:

    VA(FASTWORD(FASTWORD_BITS - 1) == 0, "%s: FASTWORD() failed", __func__);

As the self-test program used array-like data structures, I needed to inspact those as well, so I output those before doing the tests, resulting in a lot of output even when all tests succeed.

So I invented another macro, VFA() (verbose failed assertion) that uses a "lambda parameter" like this:

#define VFA(assert_cond, cmd, msg, ...) do {    \
    if ( !(assert_cond) ) { \
        E(msg, ##__VA_ARGS__); \
        cmd; \
    } \
    assert(assert_cond); \
} while (0)

While writing that I wondered how the preprocessor would parse commata for a use case like this:

    VFA(fw[0] == out_fw0 && fw[1] == out_fw1,
        dump_fastwords_range(fw, 4, pos, (pos + count) % FASTWORD_BITS),
        "%s: __clear_fw_bits_up(%d, %d) failed", context, pos, count);

I mean it could be possible that the condition could be the first parameter, dump_fastwords_range(fw could be the second, 4 could be the third, and so on...

However that is not the case with gcc at least.

The other thing is cmd; in the macro: My first version did not include the semicolon, so I would have to write (which looks really ugly):

    VFA(fw[0] == out_fw0 && fw[1] == out_fw1,
        dump_fastwords_range(fw, 4, pos, (pos + count) % FASTWORD_BITS);,
        "%s: __clear_fw_bits_up(%d, %d) failed", context, pos, count);

OK, here's another use example of my macro:

    VFA(fw[0] == out_fw0 && fw[1] == out_fw1,
    {
        const unsigned first = pos >= count ?
            pos - count : FASTWORD_BITS + pos - count + 1;

        dump_fastwords_range(fw, 4, first, pos);
    },
        "%s: __clear_fw_bits_dn(%d, %d) failed", context, pos, count);

Questions

The questions I have are:

  1. Is parsing of the macro parameters portable across compilers?
  2. Will the cmd use create any trouble, considering the parameter could be rather complex (as the last example suggests)?

Upvotes: 0

Views: 96

Answers (1)

Lundin
Lundin

Reputation: 214395

Is parsing of the macro parameters portable across compilers?

No. ##__VA_ARGS__ is a non-portable gcc extension. What does ##__VA_ARGS__ mean?

Will the cmd use create any trouble, considering the parameter could be rather complex (as the last example suggests)?

Items within () of that macro parameter will mean that it all gets treated like a single pre-processor token and expanded as such. You can peek at the pre-processor output if you are curious. Formally this is specified in C17 6.10.3/10:

Each subsequent instance of the function-like macro name followed by a ( as the next preprocessing token introduces the sequence of preprocessing tokens that is replaced by the replacement list in the definition (an invocation of the macro). The replaced sequence of preprocessing tokens is terminated by the matching ) preprocessing token, skipping intervening matched pairs of left and right parenthesis preprocessing tokens.

So it shouldn't create any trouble unless you do truly evil stuff like using goto or setjmp etc from inside it.

Upvotes: 1

Related Questions