434
|
1 /* Compile-time assert-like macros.
|
|
2
|
|
3 Copyright (C) 2005-2006, 2009-2010 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
|