On 05/29/11 06:08, Bruno Haible wrote:
> Hi Paul,
>
>>> "verify.h" no longer defines the 'verify' macro if
>>> was already included in the same compilation unit.
>>
>> Thanks, I pushed this fix:
>
> This is better: The error is gone. But there are warnings now:
Thanks for catching that. I appl
Paul Eggert wrote:
> +assert.h: assert.in.h verify.h $(top_builddir)/config.status
> + $(AM_V_GEN)rm -f $@-t $@ && \
> + { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */' && \
> + sed -e 's|@''INCLUDE_NEXT''@|$(INCLUDE_NEXT)|g' \
> + -e 's|@''PRAGMA_SYSTEM_HEADER''@|@PRAG
Hi Paul,
> > "verify.h" no longer defines the 'verify' macro if
> > was already included in the same compilation unit.
>
> Thanks, I pushed this fix:
This is better: The error is gone. But there are warnings now:
$ ./gnulib-tool --test assert-h exclude
...
In file included from ../../gllib/exc
On 05/22/11 16:09, Bruno Haible wrote:
> "verify.h" no longer defines the 'verify' macro if
> was already included in the same compilation unit.
Thanks, I pushed this fix:
verify: fix bug when gnulib is also included
* lib/verify.h (verify, verify_true): Define if _GL_VERIFY_H
is defined, not i
Hi Paul,
> Here's what I pushed. Thanks to Bruno and Eric for the reviews.
>
> ---
> ChangeLog | 22 +++
> doc/posix-headers/assert.texi | 21 ++-
> lib/assert.in.h | 28 +
> lib/verify.h | 130
>
On Thu 05 May 2011, Bruno Haible wrote:
> Hi Paul,
>
>> it's also nice to support the standard syntax.
>
> Nice work, thanks. Just three remarks:
>
> - A doc update of doc/posix-headers/assert.texi would be useful.
>
> - Use of __ prefixed identifiers:
>> + struct __gl_verify_type {
>> ...
>> +
Here's what I pushed. Thanks to Bruno and Eric for the reviews.
---
ChangeLog | 22 +++
doc/posix-headers/assert.texi | 21 ++-
lib/assert.in.h | 28 +
lib/verify.h | 130 +
m4/asser
On 05/05/11 10:48, Bruno Haible wrote:
> But with gnulib, we have three territories: the C implementation, gnulib,
> and the application. From the point of the C implementation, gnulib is
> application code. From the point of the application, gnulib is part of the
> C implementation. So we have to
On 05/05/11 10:24, Eric Blake wrote:
>> +In C99, @code{assert} can be applied to any scalar expression.
>> > +In C89, the argument to @code{assert} is of type @code{int}.
> Is it worth trying to fix that in gnulib, as an independent fix? Are
> there any implementations where assert(0x1LL)
Hi Paul,
> > Identifiers starting with __ are in the namespace of compiler and libc
> > implementation.
>
> Identifiers starting with "_G" are also reserved
In the terminology of the standards, there's only the C implementation and
the application. The term "reserved" draws the borderline be
On 05/05/2011 11:15 AM, Paul Eggert wrote:
> On 05/05/11 01:10, Bruno Haible wrote:
>> - A doc update of doc/posix-headers/assert.texi would be useful.
>
> Thanks for catching that. A further draft patch is below. It also
> notes a minor difference between C89 and C99 'assert'.
>
>> Identifie
On 05/05/11 01:10, Bruno Haible wrote:
> - A doc update of doc/posix-headers/assert.texi would be useful.
Thanks for catching that. A further draft patch is below. It also
notes a minor difference between C89 and C99 'assert'.
> Identifiers starting with __ are in the namespace of compiler an
Hi Paul,
> it's also nice to support the standard syntax.
Nice work, thanks. Just three remarks:
- A doc update of doc/posix-headers/assert.texi would be useful.
- Use of __ prefixed identifiers:
> + struct __gl_verify_type {
> ...
> + int __gl_dummy; \
> ...
> +
13 matches
Mail list logo
