Bruno Haible <[EMAIL PROTECTED]> 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.
_______________________________________________
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
