Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > more portable compile-time assert()

Reply
Thread Tools

more portable compile-time assert()

 
 
Francois Grieu
Guest
Posts: n/a
 
      01-11-2008
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
 
Reply With Quote
 
 
 
 
Laurent Deniau
Guest
Posts: n/a
 
      01-11-2008
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_v oid_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.
 
Reply With Quote
 
 
 
 
Walter Roberson
Guest
Posts: n/a
 
      01-11-2008
In article <(E-Mail Removed)>,
Francois Grieu <(E-Mail Removed)> wrote:

>#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.
--
"Any sufficiently advanced bug is indistinguishable from a feature."
-- Rich Kulawiec
 
Reply With Quote
 
Ben Pfaff
Guest
Posts: n/a
 
      01-11-2008
Francois Grieu <(E-Mail Removed)> writes:

[...compile-time assert macro...]
> Anything more robust, and less heavy on namespace polution ?


There's a carefully documented solution at:
http://git.sv.gnu.org/gitweb/?p=gnul...51196c910dcc25
--
Ben Pfaff
http://benpfaff.org
 
Reply With Quote
 
Toms hilidhe
Guest
Posts: n/a
 
      01-11-2008
Laurent Deniau <(E-Mail Removed)> wrote in comp.lang.c:


> 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.

--
Toms hilidhe
 
Reply With Quote
 
Francois Grieu
Guest
Posts: n/a
 
      01-11-2008
On Jan 11, 6:09 pm, (E-Mail Removed)-cnrc.gc.ca (Walter Roberson)
wrote:
> In article <(E-Mail Removed)>,
> Francois Grieu <(E-Mail Removed)> wrote:
>
> >#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 ?


<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(0x1234567 &&
1==sizeof LOW8(1.)
);
 
Reply With Quote
 
Malcolm McLean
Guest
Posts: n/a
 
      01-11-2008

"Tomás Ó hÉilidhe" <(E-Mail Removed)> wrote in message
>
> 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.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm


 
Reply With Quote
 
Walter Roberson
Guest
Posts: n/a
 
      01-11-2008
In article <(E-Mail Removed)>,
Malcolm McLean <(E-Mail Removed)> wrote:

>"Tomás Ó hÉilidhe" <(E-Mail Removed)> wrote in message


>> 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.


Unfortunately the preprocessor will not evaluate sizeof()
(or at least not and get the sizes that would be generated at compile time!)
--
"I will speculate that [...] applications [...] could actually see a
performance boost for most users by going dual-core [...] because it
is running the adware and spyware that [...] are otherwise slowing
down the single CPU that user has today" -- Herb Sutter
 
Reply With Quote
 
Ark Khasin
Guest
Posts: n/a
 
      01-12-2008
"Tom��������������� ���������������� " wrote:
> Laurent Deniau <(E-Mail Removed)> wrote in comp.lang.c:
>
>
>> 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.
>

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

--
Ark

 
Reply With Quote
 
Justin Spahr-Summers
Guest
Posts: n/a
 
      01-13-2008
On Jan 11, 11:14 am, "Toms hilidhe" <(E-Mail Removed)> wrote:
> Laurent Deniau <(E-Mail Removed)> wrote in comp.lang.c:
>
> > 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.


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__.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Portable Python - free portable development environment ! perica.zivkovic@gmail.com Python 7 01-13-2007 11:19 AM
Kamaelia 0.4.0 RELEASED - Faster! More Tools! More Examples! More Docs! ;-) Michael Python 4 06-26-2006 08:00 AM
What gcc options guarantee more portable C code lovecreatesbeauty C Programming 28 06-17-2006 01:13 AM
portable (VHDL) vs. non-portable (altera LPM) approaches to signed computations Eli Bendersky VHDL 1 03-01-2006 02:43 PM
With a Ruby Yell: more, more more! Robert Klemme Ruby 5 09-29-2005 06:37 AM



Advertisments