doc/verify.texi

   1 @c GNU verify module documentation
   2
   3 @c Copyright (C) 2006, 2009-2013 Free Software Foundation, Inc.
   4
   5 @c Permission is granted to copy, distribute and/or modify this document
   6 @c under the terms of the GNU Free Documentation License, Version 1.3
   7 @c or any later version published by the Free Software Foundation;
   8 @c with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
   9 @c Texts.  A copy of the license is included in the ``GNU Free
  10 @c Documentation License'' file as part of this distribution.
  11
  12 @node Compile-time Assertions
  13 @section Compile-time Assertions
  14
  15 @cindex assertion
  16 @findex verify
  17 @findex verify_expr
  18
  19 This module provides a header file @file{verify.h} that defines
  20 macros related to compile-time verification.
  21
  22 Two of these macros are @code{verify (@var{V})} and @code{verify_expr
  23 (@var{V}, @var{EXPR})}.  Both accept an integer constant expression
  24 argument @var{V} and verify that it is nonzero.  If not, a compile-time error
  25 results.
  26
  27 These two macros implement compile-time tests, as opposed to
  28 the standard @code{assert} macro which supports only runtime tests.
  29 Since the tests occur at compile-time, they are more reliable, and
  30 they require no runtime overhead.
  31
  32 @code{verify (@var{V});} is a declaration; it can occur outside of
  33 functions.  In contrast, @code{verify_expr (@var{V}, @var{EXPR})} is
  34 an expression that returns the value of @var{EXPR}; it can be used in
  35 macros that expand to expressions.  If @var{EXPR} is an integer
  36 constant expression, then @code{verify_expr (@var{V}, @var{EXPR})} is
  37 also an integer constant expression.  Although @var{EXPR} and
  38 @code{verify_expr (@var{V}, @var{EXPR})}@ are guaranteed to have the
  39 same side effects and value and type (after integer promotion), they
  40 need not have the same type if @var{EXPR}'s type is an integer that is
  41 narrower than @code{int} or @code{unsigned int}.
  42
  43 @var{V} should be an integer constant expression in the sense
  44 of the C standard.  Its leaf operands should be integer, enumeration,
  45 or character constants; or @code{sizeof} expressions that return
  46 constants; or floating constants that are the immediate operands of
  47 casts.  Outside a @code{sizeof} subexpression, @var{V} should
  48 not contain any assignments, function calls, comma operators, casts to
  49 non-integer types, or subexpressions whose values are outside the
  50 representable ranges for their types.  If @var{V} is not an
  51 integer constant expression, then a compiler might reject a usage like
  52 @samp{verify (@var{V});} even when @var{V} is
  53 nonzero.
  54
  55 Although the standard @code{assert} macro is a runtime test, C11
  56 specifies a builtin @code{_Static_assert (@var{V},
  57 @var{STRING-LITERAL})}, its @file{assert.h} header has a similar macro
  58 named @code{static_assert}, and C++11 has a similar
  59 @code{static_assert} builtin.  These builtins and macros differ
  60 from @code{verify} in two major ways.  First, they can also be used
  61 within a @code{struct} or @code{union} specifier, in place of an
  62 ordinary member declaration.  Second, they require the programmer to
  63 specify a compile-time diagnostic as a string literal.
  64
  65 The @file{verify.h} header defines one more macro, @code{assume
  66 (@var{E})}, which expands to an expression of type @code{void}
  67 that causes the compiler to assume that @var{E} yields a nonzero
  68 value.  @var{E} should be a scalar expression, and should not
  69 have side effects; it may or may not be evaluated.  The behavior is
  70 undefined if @var{E} would yield zero.  The main use of @code{assume}
  71 is optimization, as the compiler may be able to generate better code
  72 if it assumes @var{E}.  For best results, @var{E} should be simple
  73 enough that a compiler can determine that it has no side effects: if
  74 @var{E} calls an external function or accesses volatile storage the
  75 compiler may not be able to optimize @var{E} away and @code{assume
  76 (@var{E})} may therefore slow down the program.
  77
  78 Here are some example uses of these macros.
  79
  80 @example
  81 #include <verify.h>
  82
  83 #include <limits.h>
  84 #include <time.h>
  85
  86 /* Verify that time_t is an integer type.  */
  87 verify ((time_t) 1.5 == 1);
  88
  89 /* Verify that time_t is no smaller than int.  */
  90 verify (sizeof (int) <= sizeof (time_t));
  91
  92 /* Verify that time_t is signed.  */
  93 verify ((time_t) -1 < 0);
  94
  95 /* Verify that time_t uses two's complement representation.  */
  96 verify (~ (time_t) -1 == 0);
  97
  98 /* Return the maximum value of the integer type T,
  99    verifying that T is an unsigned integer type.
 100    The cast to (T) is outside the call to verify_expr
 101    so that the result is of type T
 102    even when T is narrower than unsigned int.  */
 103 #define MAX_UNSIGNED_VAL(t) \
 104    ((T) verify_expr (0 < (T) -1, -1))
 105
 106 /* Return T divided by CHAR_MAX + 1, where behavior is
 107    undefined if T < 0.  In the common case where CHAR_MAX
 108    is 127 the compiler can therefore implement the division
 109    by shifting T right 7 bits, an optimization that would
 110    not be valid if T were negative.  */
 111 time_t
 112 time_index (time_t t)
 113 @{
 114   assume (0 <= t);
 115   return t / (CHAR_MAX + 1);
 116 @}
 117
 118
 119 @end example