Static assert of define

Hi,

I was wondering how can we extend simple macro like

Code:

---

#define TOGGLE_BIT(x,y) \
        (x) ^= (1 << (y))

---

with static assertion - i.e verify if y is within 32 bits as shifting beyound is undefined. However this simple task seems to impossible in C. First, naive attempt would be sth like

Code:

---

#define TOGGLE_BIT(x,y) \
#if (y < 32)
        (x) ^= (1 << (y))
#else
#error Requested bit out of integer bouds
#endif

---

But this won't work because preprocessor does only one pass, IOW it won't allow for other directives in #define

Other apprach would be:

Code:

---

#define TOGGLE_BIT(x,y) \
static_assert((y > 31),"Out of integer bound")
        (x) ^= (1 << (y))

---

but then the macro is preatty much useless - you can't use t in the assignment or inside if() condition.

So how can we cope with that?

How do you expect the compile time pre-processor to deal with run-time values?

If you want to do this, make it an inline function rather than a macro.

This is not about real time values but constants like IS_BIT_SET(255,8)

What examples of use in context do you have?

The usage is as I mention - the programmer will always use the macro with constants known at compile time. Now the question is if we can verify them inside that #define ?

The inline function idea might be worth a try: while inlining isn't guaranteed, if it does happen (and the code does look like a good candidate for inlining), it may be possible that the compiler will do constant propagation and then eliminate the branch that it can determine will never be executed.

Quote:

---

Originally Posted by MartinR

The usage is as I mention - the programmer will always use the macro with constants known at compile time. Now the question is if we can verify them inside that #define ?

---

Usage - like

Code:

---

if ( IS_BIT_SET(255,8) ) {
  // do something
}

---

Really limits your options as to what is syntactically valid inside your macro.

Things which can exist as statements have more scope.

Code:

---

#define STATIC_ASSERT(COND,MSG) typedef char static_assertion_##MSG[(COND)?1:-1]

#define TOGGLE_BIT(x,y) do {          \
  STATIC_ASSERT((y<32),out_of_bound); \
  (x) ^= (1 << (y));                  \
} while ( 0 )

int main ( ) {
  int x = 0;
  TOGGLE_BIT(x,44);
}


$ gcc foo.c
foo.c: In function ‘main’:
foo.c:1:46: error: size of array ‘static_assertion_out_of_bound’ is negative
 #define STATIC_ASSERT(COND,MSG) typedef char static_assertion_##MSG[(COND)?1:-1]
                                              ^
foo.c:4:3: note: in expansion of macro ‘STATIC_ASSERT’
  STATIC_ASSERT((y<32),out_of_bound); \
  ^
foo.c:10:3: note: in expansion of macro ‘TOGGLE_BIT’
  TOGGLE_BIT(x,44);
  ^
foo.c:5:13: warning: left shift count >= width of type [-Wshift-count-overflow]
  (x) ^= (1 << (y));                  \
            ^
foo.c:10:3: note: in expansion of macro ‘TOGGLE_BIT’
  TOGGLE_BIT(x,44);
  ^

---

But note that gcc already knows how to warn you about these things if the shift is known at compile time.

@Salem, thanks for extended answer!

The trick with

Code:

---

typedef char static_assertion_##MSG[(COND)?1:-1]

---

is nice and I saw it before in some legacy code. But shouldn't compiler complain about redefinition of a typedef?

Quote:

---

But note that gcc already knows how to warn you about these things if the shift is known at compile time.

---

Yes I know, I was just theoretically considering own assertion method.

> But shouldn't compiler complain about redefinition of a typedef?
Well each is scoped by the braces of the do-while, so no.