Octave-Forge - Extra packages for GNU Octave | |
Home · Packages · Developers · Documentation · FAQ · Bugs · Mailing Lists · Links · Code |
00001 /* -*- buffer-read-only: t -*- vi: set ro: */ 00002 /* DO NOT EDIT! GENERATED AUTOMATICALLY! */ 00003 /* Compile-time assert-like macros. 00004 00005 Copyright (C) 2005-2006, 2009-2011 Free Software Foundation, Inc. 00006 00007 This program is free software: you can redistribute it and/or modify 00008 it under the terms of the GNU General Public License as published by 00009 the Free Software Foundation; either version 3 of the License, or 00010 (at your option) any later version. 00011 00012 This program is distributed in the hope that it will be useful, 00013 but WITHOUT ANY WARRANTY; without even the implied warranty of 00014 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 00015 GNU General Public License for more details. 00016 00017 You should have received a copy of the GNU General Public License 00018 along with this program. If not, see <http://www.gnu.org/licenses/>. */ 00019 00020 /* Written by Paul Eggert, Bruno Haible, and Jim Meyering. */ 00021 00022 #ifndef VERIFY_H 00023 # define VERIFY_H 1 00024 00025 /* Each of these macros verifies that its argument R is nonzero. To 00026 be portable, R should be an integer constant expression. Unlike 00027 assert (R), there is no run-time overhead. 00028 00029 There are two macros, since no single macro can be used in all 00030 contexts in C. verify_true (R) is for scalar contexts, including 00031 integer constant expression contexts. verify (R) is for declaration 00032 contexts, e.g., the top level. 00033 00034 Symbols ending in "__" are private to this header. 00035 00036 The code below uses several ideas. 00037 00038 * The first step is ((R) ? 1 : -1). Given an expression R, of 00039 integral or boolean or floating-point type, this yields an 00040 expression of integral type, whose value is later verified to be 00041 constant and nonnegative. 00042 00043 * Next this expression W is wrapped in a type 00044 struct verify_type__ { unsigned int verify_error_if_negative_size__: W; }. 00045 If W is negative, this yields a compile-time error. No compiler can 00046 deal with a bit-field of negative size. 00047 00048 One might think that an array size check would have the same 00049 effect, that is, that the type struct { unsigned int dummy[W]; } 00050 would work as well. However, inside a function, some compilers 00051 (such as C++ compilers and GNU C) allow local parameters and 00052 variables inside array size expressions. With these compilers, 00053 an array size check would not properly diagnose this misuse of 00054 the verify macro: 00055 00056 void function (int n) { verify (n < 0); } 00057 00058 * For the verify macro, the struct verify_type__ will need to 00059 somehow be embedded into a declaration. To be portable, this 00060 declaration must declare an object, a constant, a function, or a 00061 typedef name. If the declared entity uses the type directly, 00062 such as in 00063 00064 struct dummy {...}; 00065 typedef struct {...} dummy; 00066 extern struct {...} *dummy; 00067 extern void dummy (struct {...} *); 00068 extern struct {...} *dummy (void); 00069 00070 two uses of the verify macro would yield colliding declarations 00071 if the entity names are not disambiguated. A workaround is to 00072 attach the current line number to the entity name: 00073 00074 #define _GL_CONCAT0(x, y) x##y 00075 #define _GL_CONCAT(x, y) _GL_CONCAT0 (x, y) 00076 extern struct {...} * _GL_CONCAT (dummy, __LINE__); 00077 00078 But this has the problem that two invocations of verify from 00079 within the same macro would collide, since the __LINE__ value 00080 would be the same for both invocations. (The GCC __COUNTER__ 00081 macro solves this problem, but is not portable.) 00082 00083 A solution is to use the sizeof operator. It yields a number, 00084 getting rid of the identity of the type. Declarations like 00085 00086 extern int dummy [sizeof (struct {...})]; 00087 extern void dummy (int [sizeof (struct {...})]); 00088 extern int (*dummy (void)) [sizeof (struct {...})]; 00089 00090 can be repeated. 00091 00092 * Should the implementation use a named struct or an unnamed struct? 00093 Which of the following alternatives can be used? 00094 00095 extern int dummy [sizeof (struct {...})]; 00096 extern int dummy [sizeof (struct verify_type__ {...})]; 00097 extern void dummy (int [sizeof (struct {...})]); 00098 extern void dummy (int [sizeof (struct verify_type__ {...})]); 00099 extern int (*dummy (void)) [sizeof (struct {...})]; 00100 extern int (*dummy (void)) [sizeof (struct verify_type__ {...})]; 00101 00102 In the second and sixth case, the struct type is exported to the 00103 outer scope; two such declarations therefore collide. GCC warns 00104 about the first, third, and fourth cases. So the only remaining 00105 possibility is the fifth case: 00106 00107 extern int (*dummy (void)) [sizeof (struct {...})]; 00108 00109 * GCC warns about duplicate declarations of the dummy function if 00110 -Wredundant_decls is used. GCC 4.3 and later have a builtin 00111 __COUNTER__ macro that can let us generate unique identifiers for 00112 each dummy function, to suppress this warning. 00113 00114 * This implementation exploits the fact that GCC does not warn about 00115 the last declaration mentioned above. If a future version of GCC 00116 introduces a warning for this, the problem could be worked around 00117 by using code specialized to GCC, just as __COUNTER__ is already 00118 being used if available. 00119 00120 #if 4 <= __GNUC__ 00121 # define verify(R) [another version to keep GCC happy] 00122 #endif 00123 00124 * In C++, any struct definition inside sizeof is invalid. 00125 Use a template type to work around the problem. */ 00126 00127 /* Concatenate two preprocessor tokens. */ 00128 # define _GL_CONCAT(x, y) _GL_CONCAT0 (x, y) 00129 # define _GL_CONCAT0(x, y) x##y 00130 00131 /* _GL_COUNTER is an integer, preferably one that changes each time we 00132 use it. Use __COUNTER__ if it works, falling back on __LINE__ 00133 otherwise. __LINE__ isn't perfect, but it's better than a 00134 constant. */ 00135 # if defined __COUNTER__ && __COUNTER__ != __COUNTER__ 00136 # define _GL_COUNTER __COUNTER__ 00137 # else 00138 # define _GL_COUNTER __LINE__ 00139 # endif 00140 00141 /* Generate a symbol with the given prefix, making it unique if 00142 possible. */ 00143 # define _GL_GENSYM(prefix) _GL_CONCAT (prefix, _GL_COUNTER) 00144 00145 /* Verify requirement R at compile-time, as an integer constant expression. 00146 Return 1. */ 00147 00148 # ifdef __cplusplus 00149 template <int w> 00150 struct verify_type__ { unsigned int verify_error_if_negative_size__: w; }; 00151 # define verify_true(R) \ 00152 (!!sizeof (verify_type__<(R) ? 1 : -1>)) 00153 # else 00154 # define verify_true(R) \ 00155 (!!sizeof \ 00156 (struct { unsigned int verify_error_if_negative_size__: (R) ? 1 : -1; })) 00157 # endif 00158 00159 /* Verify requirement R at compile-time, as a declaration without a 00160 trailing ';'. */ 00161 00162 # define verify(R) \ 00163 extern int (* _GL_GENSYM (verify_function) (void)) [verify_true (R)] 00164 00165 #endif