• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
1 /* Compile-time assert-like macros.
2 
3    Copyright (C) 2005, 2006 Free Software Foundation, Inc.
4 
5    This program is free software: you can redistribute it and/or modify
6    it under the terms of the GNU General Public License as published by
7    the Free Software Foundation; either version 3 of the License, or
8    (at your option) any later version.
9 
10    This program is distributed in the hope that it will be useful,
11    but WITHOUT ANY WARRANTY; without even the implied warranty of
12    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
13    GNU General Public License for more details.
14 
15    You should have received a copy of the GNU General Public License
16    along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
17 
18 /* Written by Paul Eggert, Bruno Haible, and Jim Meyering.  */
19 
20 #ifndef VERIFY_H
21 # define VERIFY_H 1
22 
23 /* Each of these macros verifies that its argument R is nonzero.  To
24    be portable, R should be an integer constant expression.  Unlike
25    assert (R), there is no run-time overhead.
26 
27    There are two macros, since no single macro can be used in all
28    contexts in C.  verify_true (R) is for scalar contexts, including
29    integer constant expression contexts.  verify (R) is for declaration
30    contexts, e.g., the top level.
31 
32    Symbols ending in "__" are private to this header.
33 
34    The code below uses several ideas.
35 
36    * The first step is ((R) ? 1 : -1).  Given an expression R, of
37      integral or boolean or floating-point type, this yields an
38      expression of integral type, whose value is later verified to be
39      constant and nonnegative.
40 
41    * Next this expression W is wrapped in a type
42      struct verify_type__ { unsigned int verify_error_if_negative_size__: W; }.
43      If W is negative, this yields a compile-time error.  No compiler can
44      deal with a bit-field of negative size.
45 
46      One might think that an array size check would have the same
47      effect, that is, that the type struct { unsigned int dummy[W]; }
48      would work as well.  However, inside a function, some compilers
49      (such as C++ compilers and GNU C) allow local parameters and
50      variables inside array size expressions.  With these compilers,
51      an array size check would not properly diagnose this misuse of
52      the verify macro:
53 
54        void function (int n) { verify (n < 0); }
55 
56    * For the verify macro, the struct verify_type__ will need to
57      somehow be embedded into a declaration.  To be portable, this
58      declaration must declare an object, a constant, a function, or a
59      typedef name.  If the declared entity uses the type directly,
60      such as in
61 
62        struct dummy {...};
63        typedef struct {...} dummy;
64        extern struct {...} *dummy;
65        extern void dummy (struct {...} *);
66        extern struct {...} *dummy (void);
67 
68      two uses of the verify macro would yield colliding declarations
69      if the entity names are not disambiguated.  A workaround is to
70      attach the current line number to the entity name:
71 
72        #define GL_CONCAT0(x, y) x##y
73        #define GL_CONCAT(x, y) GL_CONCAT0 (x, y)
74        extern struct {...} * GL_CONCAT(dummy,__LINE__);
75 
76      But this has the problem that two invocations of verify from
77      within the same macro would collide, since the __LINE__ value
78      would be the same for both invocations.
79 
80      A solution is to use the sizeof operator.  It yields a number,
81      getting rid of the identity of the type.  Declarations like
82 
83        extern int dummy [sizeof (struct {...})];
84        extern void dummy (int [sizeof (struct {...})]);
85        extern int (*dummy (void)) [sizeof (struct {...})];
86 
87      can be repeated.
88 
89    * Should the implementation use a named struct or an unnamed struct?
90      Which of the following alternatives can be used?
91 
92        extern int dummy [sizeof (struct {...})];
93        extern int dummy [sizeof (struct verify_type__ {...})];
94        extern void dummy (int [sizeof (struct {...})]);
95        extern void dummy (int [sizeof (struct verify_type__ {...})]);
96        extern int (*dummy (void)) [sizeof (struct {...})];
97        extern int (*dummy (void)) [sizeof (struct verify_type__ {...})];
98 
99      In the second and sixth case, the struct type is exported to the
100      outer scope; two such declarations therefore collide.  GCC warns
101      about the first, third, and fourth cases.  So the only remaining
102      possibility is the fifth case:
103 
104        extern int (*dummy (void)) [sizeof (struct {...})];
105 
106    * This implementation exploits the fact that GCC does not warn about
107      the last declaration mentioned above.  If a future version of GCC
108      introduces a warning for this, the problem could be worked around
109      by using code specialized to GCC, e.g.,:
110 
111        #if 4 <= __GNUC__
112        # define verify(R) \
113 	   extern int (* verify_function__ (void)) \
114 		      [__builtin_constant_p (R) && (R) ? 1 : -1]
115        #endif
116 
117    * In C++, any struct definition inside sizeof is invalid.
118      Use a template type to work around the problem.  */
119 
120 
121 /* Verify requirement R at compile-time, as an integer constant expression.
122    Return 1.  */
123 
124 # ifdef __cplusplus
125 template <int w>
126   struct verify_type__ { unsigned int verify_error_if_negative_size__: w; };
127 #  define verify_true(R) \
128      (!!sizeof (verify_type__<(R) ? 1 : -1>))
129 # else
130 #  define verify_true(R) \
131      (!!sizeof \
132       (struct { unsigned int verify_error_if_negative_size__: (R) ? 1 : -1; }))
133 # endif
134 
135 /* Verify requirement R at compile-time, as a declaration without a
136    trailing ';'.  */
137 
138 # define verify(R) extern int (* verify_function__ (void)) [verify_true (R)]
139 
140 #endif
141