Re: new gnulib module "verify" for compile-time assertions

[Jim Meyering]

Bruno Haible <address@hidden> wrote:

> Jim Meyering wrote:
>> 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.
>
> Ah, I see. That wasn't clear from the comments.
>
>> 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>
>
> This one also has some interesting trick.
>
>> Just don't use verify twice on the same line.
>
> That's not a useful restriction. GNU clisp for example uses lots of
> macros that expand into C compound statements, and often several of them
> are triggered from the same line of code.

But it may be an *acceptable* restriction.
You say `statements'.  Do you mean non-declaration statements?
If so, verify_expr would work.

Do you expect to need to use `verify' (as opposed to verify_expr)
from within a macro?  I don't.  I write relatively few macros that are
destined to be used in a declaration-only context (that is the only case
in which verify must be used, since verify_expr won't work there).

I'm all for making the code more generic, *if there is a need*.
But if no one ever actually *has to* use verify twice on the
same line, then it seems like overkill to make this header require
an autoconf test.

Of course, if there are non-gcc compilers that support variable
dimensioned automatic arrays, then we don't really have a choice;
adding the autoconf test would be best in that case.

Thanks for working on this.

> If we can get away without this restriction, we should.
>
> And we can. See appended patch. I committed a file tests/test-verify.c
> that you can test it against.