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'. > >> Identifiers starting with __ are in the namespace of compiler and libc >> implementation. > > Identifiers starting with "_G" are also reserved, and we usurp them,
Yes, and that is an intentional risk that we are willing to assume - if
someone provides a counterexample where our use of _GL_ clashed with an
implementation, the burden is on gnulib to fix up our problems to avoid
the clash. No different than any number of other places where we've had
to clean up shop (think back to the futimens clash a few years back,
where we used that symbol with a different signature than what
eventually got standardized into POSIX).
> so I figured we should usurp "__gl_" to be consistent. It's no big
> deal, I'll change the __gl_ prefix to a _gl_ prefix. But strictly
> speaking, as far as I can see, the following code conforms to draft
> C1X:
>
> #define _gl_static_assert_error_if_negative 100
> #include <assert.h>
> static_assert (1);
>
> and once we change __gl_ to _gl_ this (perverse) code won't work any more.
Anyone using gnulib should hopefully not be writing code this perverse.
I'm okay with _gl_ (and not the longer __gl_) along with documentation
that users of the gnulib library can't expect 100% C99 compliance and
therefore shouldn't write perverse code (for that matter, we already
document that for things like <stdbool.h>, where if you are using
gnulib, your code has to follow additional coding rules not necessary in
a fully conforming environment).
> Portability problems not fixed by Gnulib:
...
> +@item
> +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(0x100000000LL) fails instead of
succeeds, because the conversion from long long back to int lost the
non-zero bit?
--
Eric Blake ebl...@redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
