Re: Static assertions

["David Thompson" <david.thompson1@worldnet.att.net>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3432 bytes --]

Jean-Pierre Rosen <rosen@adalog.fr> wrote :
>
> "Aaro Koskinen" <aaro@iki.fi> a �crit dans le message news:
> pdx7kzd3fdb.fsf@sirppi.helsinki.fi...
...
> > I have been using a similar method in C. I have an assert macro, which
> > declares a const int with the value "1 / <static boolean expression>".
> > If the assertion does not hold, it evaluates to 0, and the code will
> > not compile.
> >
> Out of curiosity... Is this *required* by the C standard ?
>
Not clearly.  First of all, the 'const' is irrelevant; in (standard) C
a const variable is just readonly, not usable as a compile-time
value = in a "constant expression".  (In C++ a const variable
(initialized in the declaration) or static data member of a class
(initialized in the class definition) of integral or enumeration type
is a compile-time constant, and a combined C/C++ implementation
may provide this in C also as a convenient-to-do extension.)

The initializer for a variable with static duration, which means
all declared at file scope = outside any function, plus those
declared within a function body (block) with the keyword 'static',
must be an arithmetic constant expression convertible to
the correct type (C99 6.7.8p4 was C89/90 6.5.7 constraint)
(but not an "integer[ral] constant expression", which is slightly different).
(For C89/90, the elements of a braced initializer list (for an aggregate)
must also be constant expressions; for C99 they must be so only
for a static variable, for an automatic (stack) variable they need not.)

"Each constant expression shall evaluate to a constant that is in
the range of representable values for its type."  (6.6p4 was 6.4 constraint)
but "The semantic rules for the evaluation of a constant expression
are the same as for a nonconstant expressions" (6.6p11 was 6.4)
and "if the second operand [of / or %] is zero, the behavior is undefined"
(like unbounded error, 6.5.5p5 was 6.3.5, NOT a constraint).
Violating a constraint requires a diagnostic, so the question is
whether the fact that n/0 does not evaluate to a representable
constant (or indeed to any value of type 'int') is "trumped" by
the undefined behavior, which (as used many other places
in the standard) is not clearly defined (!), but is generally held
to relieve the implementation of _all_ obligations imposed.

A safer approach in pure standard C is
  char/*or anything*/ dummy [ boolexpr ];
because in C89/90 the bound in an array declarator
(ignoring the cases where it may be and is omitted)
"shall be an integral constant expression that has a value
greater than zero" (6.5.4.2 constraint) so if it is safely
evaluable and zero it is definitely a required diagnostic.
In C99 (6.7.5.2p1) this is complicated by the addition of
Variable Length Arrays, which allow the bound to be a
runtime expression in some cases and unspecified in others,
but still "If the expression is a constant expression,
it shall have a value greater than zero."

Unfortunately some compilers, notably gcc, support
bound-0 arrays as an extension, so to work there use:
  char dummy[ (boolexpr)*2-1 ];
which is strictly negative if the expression is false (0)
and a diagnosed error on every compiler I've ever seen.
If boolexpr is only nonzero/0 rather than the canonical 1/0,
and thus might overflow, do:
  char dummy[ ((expr)!=0)*2-1 ];
or in either case if you prefer:
  char dummy[ expr ? +1 : -1 ];

--
- David.Thompson 1 now at worldnet.att.net