C compiler asserts - how to implement?

Question

I'd like to implement an "assert" that prevents compilation, rather than failing at runtime, in the error case.

I currently have one defined like this, which works great, but which increases the size of the binaries.

#define MY_COMPILER_ASSERT(EXPRESSION) switch (0) {case 0: case (EXPRESSION):;}

Sample code (which fails to compile).

#define DEFINE_A 1
#define DEFINE_B 1
MY_COMPILER_ASSERT(DEFINE_A == DEFINE_B);

How can I implement this so that it does not generate any code (in order to minimize the size of the binaries generated)?

Thanks for any help. NickB

Answer 1

When you compile your final binaries, define MY_COMPILER_ASSERT to be blank, so that its output isn't included in the result. Only define it the way you have it for debugging.

But really, you aren't going to be able to catch every assertion this way. Some just don't make sense at compile time (like the assertion that a value is not null). All you can do is verify the values of other #defines. I'm not really sure why you'd want to do that.

Answer 2

If your compiler sets a preprocessor macro like DEBUG or NDEBUG you can make something like this (otherwise you could set this up in a Makefile):

#ifdef DEBUG
#define MY_COMPILER_ASSERT(EXPRESSION)   switch (0) {case 0: case (EXPRESSION):;}
#else
#define MY_COMPILER_ASSERT(EXPRESSION)
#endif

Then, your compiler asserts only for debug builds.

Answer 3

Using '#error' is a valid preprocessor definition that causes compilation to stop on most compilers. You can just do it like this, for example, to prevent compilation in debug:

#ifdef DEBUG
#error “Please don't compile now
#endif

Answer 4

The best writeup that I could find on static assertions in C is at pixelbeat. Note that static assertions are being added to C++ 0X, and may make it in to C1X, but that's not going to be for a while. I do not know if the macros in the link I gave will increase the size of your binaries. I would suspect they would not, at least if you compile at a reasonable level of optimisation, but your mileage may vary.

Answer 5

Well, you could use the static asserts in the boost library.

What I believe they do there, is to define an array.

 #define MY_COMPILER_ASSERT(EXPRESSION) char x[(EXPRESSION)];

If EXPRESSION is true, it defines char x[1];, which is OK. If false, it defines char x[0]; which is illegal.

Answer 6

I know you're interested in C, but take a look at boost's C++ static_assert. (Incidentally, this is likely becoming available in C++1x.)

We've done something similar, again for C++:

#define COMPILER_ASSERT(expr)  enum { ARG_JOIN(CompilerAssertAtLine, __LINE__) = sizeof( char[(expr) ? +1 : -1] ) }

This works only in C++, apparently. This article discusses a way to modify it for use in C.

Answer 7

The following COMPILER_VERIFY(exp) macro works fairly well.

// combine arguments (after expanding arguments)
#define GLUE(a,b) __GLUE(a,b)
#define __GLUE(a,b) a ## b

#define CVERIFY(expr, msg) typedef char GLUE (compiler_verify_, msg) [(expr) ? (+1) : (-1)]

#define COMPILER_VERIFY(exp) CVERIFY (exp, __LINE__)

It works for both C and C++ and can be used anywhere a typedef would be allowed. If the expression is true, it generates a typedef for an array of 1 char (which is harmless). If the expression is false, it generates a typedef for an array of -1 chars, which will generally result in an error message. The expression given as an arugment can be anything that evaluates to a compile-time constant (so expressions involving sizeof() work fine). This makes it much more flexible than

#if (expr)
#error
#endif

where you are restricted to expressions that can be evaluated by the preprocessor.

Answer 8

See CCASSERT here.

Answer 9

A compile-time assert in pure standard C is possible, and a little bit of preprocessor trickery makes its usage look just as clean as the runtime usage of assert().

The key trick is to find a construct that can be evaluated at compile time and can cause an error for some values. One answer is the declaration of an array cannot have a negative size. Using a typedef prevents the allocation of space on success, and preserves the error on failure.

The error message itself will cryptically refer to declaration of a negative size (GCC says "size of array foo is negative"), so you should pick a name for the array type that hints that this error really is an assertion check.

A further issue to handle is that it is only possible to typedef a particular type name once in any compilation unit. So, the macro has to arrange for each usage to get a unique type name to declare.

My usual solution has been to require that the macro have two parameters. The first is the condition to assert is true, and the second is part of the type name declared behind the scenes. The answer by plinth hints at using token pasting and the __LINE__ predefined macro to form a unique name possibly without needing an extra argument.

Unfortunately, if the assertion check is in an included file, it can still collide with a check at the same line number in a second included file, or at that line number in the main source file. We could paper over that by using the macro __FILE__, but it is defined to be a string constant and there is no preprocessor trick that can turn a string constant back into part of an identifier name; not to mention that legal file names can contain characters that are not legal parts of an identifier.

So, I would propose the following code fragment:

/** A compile time assertion check.
 *
 *  Validate at compile time that the predicate is true without
 *  generating code. This can be used at any point in a source file
 *  where typedef is legal.
 *
 *  On success, compilation proceeds normally.
 *
 *  On failure, attempts to typedef an array type of negative size. The
 *  offending line will look like
 *      typedef assertion_failed_file_h_42[-1]
 *  where file is the content of the second parameter which should
 *  typically be related in some obvious way to the containing file
 *  name, 42 is the line number in the file on which the assertion
 *  appears, and -1 is the result of a calculation based on the
 *  predicate failing.
 *
 *  \param predicate The predicate to test. It must evaluate to
 *  something that can be coerced to a normal C boolean.
 *
 *  \param file A sequence of legal identifier characters that should
 *  uniquely identify the source file in which this condition appears.
 */
#define CASSERT(predicate, file) _impl_CASSERT_LINE(predicate,__LINE__,file)

#define _impl_PASTE(a,b) a##b
#define _impl_CASSERT_LINE(predicate, line, file) \
    typedef char _impl_PASTE(assertion_failed_##file##_,line)[2*!!(predicate)-1];

A typical usage might be something like:

#include "CAssert.h"
...
struct foo { 
    ...  /* 76 bytes of members */
};
CASSERT(sizeof(struct foo) == 76, demo_c);

In GCC, an assertion failure would look like:

$ gcc -c demo.c
demo.c:32: error: size of array `assertion_failed_demo_c_32' is negative
$