Bruno Haible <[EMAIL PROTECTED]> wrote:
> Paul Eggert wrote:
>> The first step is to add a new module "verify", which defines macros
>> verify(EXPR) and verify_expr(EXPR) that act like assert(EXPR) except
>> they check EXPR at compile-time, not at run-time. verify(EXPR) is for
>> declaration contexts, and verify_expr is for expression contexts.
>
> Thanks a lot for making this generally available!
>
> At first sight, using a bitfield width instead of an array size, to
> avoid multiple-definition errors, seems awfully cool. But it does not
> work:
Hi Bruno,
The point of using a bitfield width was to ensure that improper
usage (non-constant argument) like this provokes an error even with
non-gcc compilers:
void foo (int n) { verify (n); }
With the preceding, array-dimension-based approach,
the erroneous usage would be accepted once again.
> $ cat foo.c
> #include "verify.h"
> verify (1 + 1 == 2); verify (1 + 1 == 2);
> $ gcc -O -c foo.c
> foo.c:2: conflicting types for `verify_function_2'
> foo.c:2: previous declaration of `verify_function_2'
True, this causes a problem, but it's easily avoidable.
Just don't use verify twice on the same line.
If you must have two on a line (e.g., in a macro), then use verify_expr,
assuming that's possible.
If for some reason it's important to have two on a line, we can revert
to verify.c version 1.6 in coreutils' CVS.
<http://savannah.gnu.org/cgi-bin/viewcvs/coreutils/coreutils/lib/verify.h?rev=1.6&content-type=text/plain>
That earlier incarnation of this macro used gcc's __builtin_constant_p
instead, but of course, that clause was effective only for gcc.
But considering the non-diagnosis of misuse was possible mainly with
gcc (few other compilers allow a parameter to be used as an automatic array
dimension), it's appropriate that the check for that is also gcc-specific.
Jim
_______________________________________________
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
