bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: proposed support for C1X-style static_assert


From: Bruno Haible
Subject: Re: proposed support for C1X-style static_assert
Date: Sun, 29 May 2011 15:43:20 +0200
User-agent: KMail/1.9.9

Paul Eggert wrote:
> +assert.h: assert.in.h verify.h $(top_builddir)/config.status
> +     $(AM_V_GEN)rm -f address@hidden $@ && \
> +     { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */' && \
> +       sed -e 's|@''INCLUDE_NEXT''@|$(INCLUDE_NEXT)|g' \
> +           -e 's|@''PRAGMA_SYSTEM_HEADER''@|@PRAGMA_SYSTEM_HEADER@|g' \
> +           -e 's|@''PRAGMA_COLUMNS''@|@PRAGMA_COLUMNS@|g' \
> +           -e 's|@''NEXT_ASSERT_H''@|$(NEXT_ASSERT_H)|g' \
> +           < $(srcdir)/assert.in.h && \
> +       sed -e 's|_gl_verify|_gl_static_assert|g' \
> +           -e 's|_GL_VERIFY|_GL_STATIC_ASSERT|g' \
> +           < $(srcdir)/verify.h; \
> +     } > address@hidden && \
> +     mv address@hidden $@

Now that nearly the entire verify.h is copied into assert.h, one needs
to take care not to define the same type twice.
  1. avoid collisions between assert.h and verify.h,
  2. avoid collisions between different assert.h files generated by different
     gnulib-tool invocations.

I'm applying this fix:

2011-05-29  Bruno Haible  <address@hidden>

        assert-h: Allow multiple gnulib generated replacements to coexist.
        * lib/verify.h (struct _gl_verify_type): Avoid identical redefinition.

--- lib/verify.h.orig   Sun May 29 15:36:45 2011
+++ lib/verify.h        Sun May 29 15:34:37 2011
@@ -164,10 +164,13 @@
     (!!sizeof (_GL_VERIFY_TYPE (R, DIAGNOSTIC)))
 
 # ifdef __cplusplus
+#  if !GNULIB_defined_struct__gl_verify_type
 template <int w>
   struct _gl_verify_type {
     unsigned int _gl_verify_error_if_negative: w;
   };
+#   define GNULIB_defined_struct__gl_verify_type 1
+#  endif
 #  define _GL_VERIFY_TYPE(R, DIAGNOSTIC) \
     _gl_verify_type<(R) ? 1 : -1>
 # elif defined _GL_HAVE__STATIC_ASSERT



-- 
In memoriam John Penry <http://en.wikipedia.org/wiki/John_Penry>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]