57

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)?

Improve this question
4
  • 1
    I really don't think it's possible to create a static assert in plain C, would love to know though! Commented Apr 30, 2009 at 14:42
  • Duplicate with several good answers: stackoverflow.com/questions/174356/… Commented Apr 30, 2009 at 15:07
  • 8
    Since this question is relatively old: _Static_assert and its associated macro static_assert are standardized as of C11. This is now built-in to the language. Commented Nov 22, 2015 at 2:00
  • 1
    Surely the optimizer can throw away empty switches. Commented Feb 17, 2017 at 19:13

14 Answers 14

Reset to default
59

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 $
Improve this answer
Sign up to request clarification or add additional context in comments.

6 Comments

If you don't care about portability, in GCC __COUNTER__ can be used to give a unique identifier to paste onto the typedef name. It was added fairly recently (4.3)
I've been amazed that the C preprocessor has never had something like COUNTER. Macro assemblers have had similar constructs as long as there have been macro assemblers, not to mention the ability for one macro to define another which can be used to build any kind of unique symbol one might need. Unfortunately for me, my embedded systems projects are generally stuck with gcc 3.4.5 or so, if not some proprietary compiler that (mostly) complies with C89.
@RBerteig Hello, I would like to use this code for an Open Source project. What would you licence it under?
@HannesLandeholm If I were publishing it myself, I would normally apply the MIT license. Published as it is here without any further discussion, it is fair to assume that the general claim that user content is licensed as CC-BY-SA applies. To that end, you could simply add "CC-BY-SA 3.0 from stackoverflow.com/a/809465/68204" to the comment block. Personally, I prefer not to impose the "share alike" restriction on code, but attribution and a link here is always appropriate.
This approach now triggers GCC warnings about unused typedefs, unfrotunately.
|
9

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.

Improve this answer

3 Comments

I like this but it causes a warning for an unused declared variable: main.c:22:47: warning: typedef ‘compiler_verify_39’ locally defined but not used [-Wunused-local-typedefs]. Since my project treats warnings as errors I can not use this.
Things have moved on in the decade since I posted this answer. If your compiler supports C11, you can use the _Static_assert that is now part of the language.
@Alex, this warning can be silenced with (void)(sizeof(TYPEDEF_NAME));. You might need an extra layer of dereference to pass GLUE as a parameter to the CVERIFY() macro, so that you have a TYPEDEF_NAME to work with. And (void)ENTITY; is a general way of dismissing 'unused' warnings.
5

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
Improve this answer

1 Comment

Unfortunately this aborts at the preprocessor level, so it's unable to handle things like assert(sizeof(long) == sizeof(void *)).
5

As Leander said, static assertions are being added to C++11, and now they have.

static_assert(exp, message)

For example

#include "myfile.hpp" static_assert(sizeof(MyClass) == 16, "MyClass is not 16 bytes!") void doStuff(MyClass object) { }

See the cppreference page on it.

Improve this answer

2 Comments

The question is about C not C++.
C11 provides the similarly named _Static_assert (see stackoverflow.com/a/7287341/446106). Additionally, assert.h contains a static_assert macro that maps to it (en.cppreference.com/w/c/error/static_assert)
5

Since C11, static_assert is available via <assert.h>. Since C23, static_assert is itself a keyword. https://en.cppreference.com/w/c/error/static_assert

static_assert(2 + 2 == 4, "2+2 isn't 4"); // OK static_assert(2 + 2 == 5, "2+2 isn't 4"); // Compile-time error

If for some reason you are forced to use old C standards, check this article for inspiration: https://www.pixelbeat.org/programming/gcc/static_assert.html

Improve this answer

1 Comment

With C23, static_assert(assertion); with no following string is OK too.
4

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.

Improve this answer

Comments

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.

Improve this answer

Comments

4

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.

Improve this answer

Comments

2

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.

Improve this answer

1 Comment

It is useful because anything that can be verified at compile time is something that didn't require a test case at run time. When building a portable protocol implementation it is useful to validate assumptions about structure size and layout. Since sizes and offsets are known at compile time, testing them then is preferred. Also, implementing a compile-time assert without code generation means that there is no reason to take it out of release builds. At worst it clutters the symbol table with orphan type names.
0

I found this to give the least confusing error message for GCC. Everything else had some suffix about a negative size or some other confusing thing:

#define STATIC_ASSERT(expr, msg) \ typedef char ______Assertion_Failed_____##msg[1]; __unused \ typedef char ______Assertion_Failed_____##msg[(expr)?1:2] __unused

example usage:

 unsigned char testvar; STATIC_ASSERT(sizeof(testvar) >= 8, testvar_is_too_small);

And the error message in gcc (ARM/GNU C Compiler : 6.3.1):

conflicting types for '______Assertion_Failed_____testvar_is_too_small'
Improve this answer

3 Comments

This compiler assert does not work if added in the middle of a code block since C does not allow a new declaration after executable statements.
@BitsBitsBits You mean C versions before C99?
This would be problematic if the msg will be repeated in the same file. Could be improved with some __LINE__ incorporated into the type name.
0

Who needs Rust? compile_assert works with GCC and Clang today! https://github.com/jonnygrant/compile_assert/blob/main/README.md

compile_assert

It’s not the classic “negative array size” trick and not just C11 _Static_assert. Instead it’s trying to:

Let you write runtime-looking checks - that are verified at compile time:

 compile_assert(idx < buf_len, "index in range");

inside static functions, using normal control flow.

  1. Rely on GCC/Clang optimisation and control-flow analysis so that:

  2. If the compiler can prove from all call sites that idx < buf_len is always true, it optimizes away the “bad” branch and the code compiles fine at -O2/-O3.

  3. If there exists a path where the condition is not guaranteed, the “bad” branch remains reachable and is wired to some form of “this must not happen” primitive (e.g. __builtin_unreachable() or similar UB/diagnostic trigger).

  4. That then causes a build failure or at least a hard diagnostic, pointing back to the call site where the precondition isn’t satisfied.

The repo examples show this used to check things like:

  • pointer non-NULL preconditions (compile_assert_never_null)

  • array index bounds

  • ranges of values (e.g. 0–100%)

  • offsets into buffers read from files

  • library API preconditions across translation units (example main13.c).

Improve this answer

Comments

0

Kind of depends on version of C and standard compliance. All C versions have this constraint (example from C23):

6.7.7.3 Array declarators
Constraints
...
If the expression is a constant expression, it shall have a value greater than zero.

Meaning that if we feed the compiler an array where the size is zero or negative, the compiler must produce a diagnostic message.

  • ISO C89 to ISO C99, as well as (non-conforming) GNU C89 to GNU C99:

    #define COMPILE_TIME_ASSERT(expr) {typedef char COMP_TIME_ASSERT[(expr) ? 1 : -1];}

    The outer { } are optional and should only be there in case you which to restrict this to local scope only (to prevent namespace pollution). Otherwise, if you wish to use it at file scope outside functions, remove the { }.

    GNU C allows zero-size arrays as a non-standard, non-conforming extension so therefore something like [!!(expr)] will not work in GNU C.

  • ISO C11 to ISO C17:

    _Static_assert((expr), "message");

    This is a new keyword introduced in C11. Optionally use the static_assert macro from assert.h in case C++ compatibility is important.

  • ISO C23 and onward:

    static_assert((expr), "optional message");

    In C23 static_assert is a new keyword and the 2nd message parameter may be omitted. _Static_assert remains as an alternative spelling.

Improve this answer

Comments

0

As mentioned in other answers, static_assert() in C11 is doing exactly that. In earlier C versions it can be "simulated" with some compiler black magic:

#define static_assert(condition, text) ((void)sizeof(char[1 - 2 * !(condition)]))

This works exactly like the C11 version apart from the less elegant error message.

Improve this answer

1 Comment

What does this answer add that wasn't already said in previous answers?
-3

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.

Improve this answer

3 Comments

But in C89 that would break compiling no matter what since variables can only be declared at the top of the scope. Maybe wrapping it in curly brackets might fix it? Also, zero-sized arrays are only forbidden in ISO C I think. You would also get a slew of warnings about multiple declarations and unused variables if not in its own scope.
#define MY_COMPILER_ASSERT(EXPRESSION) do {char x[(EXPRESSION)?1:-1];} while (0) would be better: inside braces, so declaration is legal and scoped, sizes 1 and -1 are clearly valid/invalid on all C versions, and forces you to MY_COMPILER_ASSERT(...); with a trailing semicolon, for visual consistency with all other function-like things in C.
Declaring a typedef is preferable to delaring an unused variable. An unused typedef is harmless, but an unused variable may itself generate a warning on many compilers.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.