more portable compile-time assert()

F

Francois Grieu

Hi,

I'm using an assert()-like macro to test a constant expression at
compile time

#define ASSERT(condition) struct{char assert_failure[(condition)?
1:-1];}

The idea is that this macro cause a compilation error if a constant
condition
is not true (or if the condition is not constant), with some
(admitedly cryptic)
error message, e.g. "error: size of array `assert_failure' is
negative".
This works including for expression involving sizeof, and casts
(assuming the compiler is not broken and knows how to perform
arithmetic
as the target system does), for examples

struct { char this, that; } foo;
ASSERT(2 == sizeof foo); // check size of foo

#define LOW8(x) ((unsigned char)(x))
ASSERT(LOW8(0x1A5)==0xA5); // check LOW8 works

int main(void) {return 0;}


This works on several compilers, but <OT>GCC</OT> barks with a warning
on the tune of "unnamed struct/union that defines no instances".

I'm looking for a more portable alternative. Came up with

#define ASSER1(x) assert_failure_##x
#define ASSER2(x) ASSER1(x)
#define ASSERT(condition) struct ASSER2(__LINE__){char
assert_failure[(condition)?1:-1];}

which mostly works, except if ASSERT is used twice on the same line,
or worse, twice at lines with the same number in different files (this
can
occur with headers).

Anything more robust, and less heavy on namespace polution ?

TIA,

Francois Grieu
 
L

Laurent Deniau

Francois Grieu a écrit :
Hi,

I'm using an assert()-like macro to test a constant expression at
compile time

#define ASSERT(condition) struct{char assert_failure[(condition)?
1:-1];}

I am using something close to:

#define STATIC_ASSERT(tag,cond) \
enum { STATIC_ASSERT__ ## tag = 1/(cond) }

STATIC_ASSERT(sizeof_long_is_smaller_than_sizeof_void_ptr,
sizeof(long) >= sizeof(void*)
);

which reports errors like:

... invalid enum
STATIC_ASSERT__sizeof_long_is_smaller_than_sizeof_void_ptr

the enum ensures compile-time assert and avoid the problem with
runtime sizeof.

a+, ld.
 
W

Walter Roberson

Francois Grieu said:
#define LOW8(x) ((unsigned char)(x))
ASSERT(LOW8(0x1A5)==0xA5); // check LOW8 works

That assumes that unsigned char has exactly 8 bits, which is not
a good assumption. If you want the low 8 bits, why not use
bitwise-and ?

I also question whether you really want LOW8 to have a different
type than x? It is not obvious that sizeof LOW8(x) should be
different than sizeof x .

Your definition of LOW8 also does not work if x is a floating
point type, and is not certain to do anything useful if x is
a pointer.
 
T

Tomás Ó hÉilidhe

I am using something close to:


Could other people please post the compile-time asserts they're using (aka
"static asserts").

I'd like to compare them and pick the best one to use in my own code.
 
F

Francois Grieu

That assumes that unsigned char has exactly 8 bits, which is not
a good assumption. If you want the low 8 bits, why not use
bitwise-and ?

<OT> many compilers generate much better code for a cast to unsigned
char than for a bitwise AND. </OT>

An alternative might be

#include <limits.h>

// LOW8(x) efficiently casts x to unsigned char and
// keeps only the low 8 bits; result is an unsigned char
#if UCHAR_MAX==0xFF
#define LOW8(x) ((unsigned char)(x))
#else
#define LOW8(x) ((unsigned char)((unsigned char)(x)&0xFF))
#endif
ASSERT( // check LOW8 works
LOW8(0x1A5)==0xA5 &&
LOW8(0)==0 &&
LOW8(0x80)>=0 &&
LOW8(-1)>=0 &&
1==sizeof LOW8(0x12345678) &&
1==sizeof LOW8(1.)
);
 
M

Malcolm McLean

Tomás Ó hÉilidhe said:
Could other people please post the compile-time asserts they're using (aka
"static asserts").
This is basically your method for picking up compile time faults.

#if condition
#error "condition was true"
#endif

There are subtle problems with it because the #if condition is expanded by
the preprocessor, not the compiler itself, but it is the standard facility
provided and you should use it.
 
W

Walter Roberson

This is basically your method for picking up compile time faults.
#if condition
#error "condition was true"
#endif
There are subtle problems with it because the #if condition is expanded by
the preprocessor, not the compiler itself, but it is the standard facility
provided and you should use it.

Unfortunately the preprocessor will not evaluate sizeof()
(or at least not and get the sizes that would be generated at compile time!)
 
A

Ark Khasin

Tom�������������������������������� said:
Could other people please post the compile-time asserts they're using
(aka "static asserts").

I'd like to compare them and pick the best one to use in my own code.
It's been discussed here some time ago; here it is again:
#define ASSERT(condition) \
extern char dummy_assert_array[(condition)?1:-1]

and e.g. to make portability issues stand out,
ASSERT(sizeof(int)==sizeof(long));
 
J

Justin Spahr-Summers

Could other people please post the compile-time asserts they're using (aka
"static asserts").

I'd like to compare them and pick the best one to use in my own code.

I recently started using something along these lines (influenced from
somewhere, but not sure where off-hand):
#define ASSERT_NAME(name, cond) \
do { \
typedef int name ## _assertion_failed[(int)(cond) * 2 - 1]; \
} while (0)

I personally like using a "name" argument to the macro to avoid
collisions when using __LINE__.
 
A

Ark Khasin

Justin said:
I recently started using something along these lines (influenced from
somewhere, but not sure where off-hand):
#define ASSERT_NAME(name, cond) \
do { \
typedef int name ## _assertion_failed[(int)(cond) * 2 - 1]; \
} while (0)

I personally like using a "name" argument to the macro to avoid
collisions when using __LINE__.
Suggestions:
1 - Remove spurious "do{" and ";}while(0)". Then you'd be able to use
ASSERT_NAME outside of any block, where "compile-time asserts" ought to be.
2 - There is still a small chance of name collision; to avoid it safely
and forever, replace "typedef" with "extern"
3 - If #2 is done, you no longer need the "name" argument, which fact
simplifies the matters.
Hmmm... After all these are done, what remains is effectively the same
as I posted elsethread.
 
L

Laurent Deniau

Justin said:
I recently started using something along these lines (influenced from
somewhere, but not sure where off-hand):
#define ASSERT_NAME(name, cond) \
do { \
typedef int name ## _assertion_failed[(int)(cond) * 2 - 1]; \
} while (0)
I personally like using a "name" argument to the macro to avoid
collisions when using __LINE__.

Suggestions:
1 - Remove spurious "do{" and ";}while(0)". Then you'd be able to use
ASSERT_NAME outside of any block, where "compile-time asserts" ought to be.
2 - There is still a small chance of name collision; to avoid it safely
and forever, replace "typedef" with "extern"

more importantly than name collision, typedef doesn't garantee a
compile-time error:

#define ASSERT_NAME(name, cond) \
typedef int name ## _assertion_failed[(cond)?1:-1]

void f(int n)
{
ASSERT(n > 0); // compile
}
3 - If #2 is done, you no longer need the "name" argument, which fact
simplifies the matters.

providing a tag or a name should trigger some better error message.
And still name collision may happen with extern:

#define LIB_ASSERT(cond) \
extern int dummy_assert_array[(cond)?1:-1]

LIB_ASSERT(sizeof(long) >= sizeof(void*));

#define ASSERT(cond) \
extern char dummy_assert_array[(cond)?1:-1]

ASSERT(sizeof(long) >= sizeof(void*));

while this has little chance to happen, it must still be considered in
case of a third party lib use the same trick and the same name but
with a different type.
Hmmm... After all these are done, what remains is effectively the same
as I posted elsethread.

a+, ld.
 
A

Ark Khasin

Laurent said:
3 - If #2 is done, you no longer need the "name" argument, which fact
simplifies the matters.

providing a tag or a name should trigger some better error message.
And still name collision may happen with extern:

#define LIB_ASSERT(cond) \
extern int dummy_assert_array[(cond)?1:-1]

LIB_ASSERT(sizeof(long) >= sizeof(void*));

#define ASSERT(cond) \
extern char dummy_assert_array[(cond)?1:-1]

ASSERT(sizeof(long) >= sizeof(void*));

while this has little chance to happen, it must still be considered in
case of a third party lib use the same trick and the same name but
with a different type.
IMHO, third party lib should not define any of this stuff in its public
header(s).

Anyway, that's simple to deal with:
#define dummy_assert_array my_very_own_assert_array

If you still have a collision with somebody else's names, change the macro.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top