OLD | NEW |
(Empty) | |
| 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 |
OLD | NEW |