Re: [bug-gnulib] Re: proposal: lib/verify.h

2005-07-11 Thread Paul Eggert
Bruno Haible [EMAIL PROTECTED] writes:

 However, Jim's first version with the NULL pointer works in C++ too:

 #define verify_expr(R) (void) ((verify_type__ (R) *) 0)

 I'd therefore suggest to use this one.

Thanks for catching that; I followed your suggestion in coreutils.

2005-07-11  Paul Eggert  [EMAIL PROTECTED]

* verify.h (verify_expr): Use ((verify_type__ (R) *) 0), not
sizeof (verify_type__ (R)), to pacify C++ compilers.  Problem
reported by Bruno Haible.

--- verify.h.~1.4.~ 2005-07-05 00:33:50.0 -0700
+++ verify.h2005-07-11 16:13:59.0 -0700
@@ -52,6 +52,6 @@
This macro can be used in some contexts where verify cannot, and vice versa.
Return void.  */
 
-# define verify_expr(R) ((void) sizeof (verify_type__ (R)))
+# define verify_expr(R) ((void) ((verify_type__ (R) *) 0))
 
 #endif


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib


Re: proposal: lib/verify.h

2005-07-04 Thread Paul Eggert
Jim Meyering [EMAIL PROTECTED] writes:

The implementation uses a struct declaration whose name includes the
expansion of __LINE__, so there is a small chance that two uses of
verify_decl from different files will end up colliding

I thought about this problem for a bit and came up with a different
implementation where two uses can't possibly collide.  Please see below.

Also, as far as the names of the macros go, I've had second thoughts.
It seems to me that once C99 takes over, verify_decl will be the
macro that most people want to use, since you can interleave decls and
statements.  So let's call this macro verify, and the less-common
expression-oriented macro verify_expr.  Sorry for whipping you back
and forth about the names.

 # ifndef verify_decl
 #  define GL_CONCAT0(x, y) x##y

How about if we just define GL_CONCAT0 etc. unconditionally?  That's
what other .h files do.  Similarly, we shouldn't need to #undef
verify.

I installed this patch into coreutils.  Comments?

2005-07-04  Paul Eggert  [EMAIL PROTECTED]

* lib/verify.h (GL_CONCAT0, GL_CONCAT): Define unconditionally; don't
depend on whether verify_decl is defined.
(verify): Renamed from verify_decl.  All uses changed.
Use an extern function decl, as it can't possibly collide with other
decls.
(verify_expr): Renamed from verify.  All uses changed.
(verify_type__): New private macro.
(verify, verify_expr): Use it.
* src/od.c: Adjust to verify.h change.
* src/system.h (VERIFY_W_TYPEOF): Likewise.

*** lib/verify.h4 Jul 2005 17:39:48 -   1.2
--- lib/verify.h5 Jul 2005 05:16:08 -   1.3
***
*** 16,43 
 along with this program; if not, write to the Free Software Foundation,
 Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.  */
  
  #ifndef VERIFY_H
  # define VERIFY_H 1
  
! # ifndef verify_decl
! #  define GL_CONCAT0(x, y) x##y
! #  define GL_CONCAT(x, y) GL_CONCAT0 (x, y)
! 
! /* Verify requirement, R, at compile-time, as a declaration.
!The implementation uses a struct declaration whose name includes the
!expansion of __LINE__, so there is a small chance that two uses of
!verify_decl from different files will end up colliding (for example,
!f.c includes f.h and verify_decl is used on the same line in each).  */
! #  define verify_decl(R) \
! struct GL_CONCAT (ct_assert_, __LINE__) { char a[(R) ? 1 : -1]; }
! # endif
! 
! /* Verify requirement, R, at compile-time, as an expression.
!Unlike assert, there is no run-time overhead.  Unlike verify_decl,
!above, there is no risk of collision, since there is no declared name.
!This macro may be used in some contexts where the other may not, and
!vice versa.  Return void.  */
! # undef verify
! # define verify(R) ((void) sizeof (struct { char a[(R) ? 1 : -1]; }))
  
  #endif
--- 16,57 
 along with this program; if not, write to the Free Software Foundation,
 Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.  */
  
+ /* Written by Paul Eggert and Jim Meyering.  */
+ 
  #ifndef VERIFY_H
  # define VERIFY_H 1
  
! # define GL_CONCAT0(x, y) x##y
! # define GL_CONCAT(x, y) GL_CONCAT0 (x, y)
! 
! /* A type that is valid if and only R is nonzero.
!R should be an integer constant expression.
!verify_type__ and verify_error_if_negative_size__ are symbols that
!are private to this header file.  */
! 
! # define verify_type__(R) \
! struct { int verify_error_if_negative_size__[(R) ? 1 : -1]; }
! 
! /* Verify requirement R at compile-time, as a declaration.
!R should be an integer constant expression.
!Unlike assert, there is no run-time overhead.
! 
!The implementation uses __LINE__ to lessen the probability of
!generating a warning that verify_function_NNN is multiply declared.
!However, even if two declarations in different files have the same
!__LINE__, the multiple declarations are still valid C89 and C99
!code because they simply redeclare the same external function, so
!no conforming compiler will reject them outright.  */
! 
! # define verify(R) \
! extern verify_type__ (R) GL_CONCAT (verify_function_, __LINE__) (void)
! 
! /* Verify requirement R at compile-time, as an expression.
!R should be an integer constant expression.
!Unlike assert, there is no run-time overhead.
!This macro can be used in some contexts where verify cannot, and vice 
versa.
!Return void.  */
! 
! # define verify_expr(R) ((void) sizeof (verify_type__ (R)))
  
  #endif
--- src/od.c4 Jul 2005 17:40:37 -   1.162
+++ src/od.c5 Jul 2005 05:13:47 -
@@ -162,7 +162,7 @@ static const int width_bytes[] =
 
 /* Ensure that for each member of `enum size_spec' there is an
initializer in the width_bytes array.  */
-verify_decl (sizeof width_bytes / sizeof width_bytes[0] == N_SIZE_SPECS);
+verify (sizeof width_bytes / sizeof 

Re: proposal: lib/verify.h

2005-06-30 Thread Jim Meyering
Paul Eggert [EMAIL PROTECTED] wrote:
 Jim Meyering [EMAIL PROTECTED] writes:

   #define GL_CONCAT...
   #define VERIFY(assertion) \
 struct GL_CONCAT (compile_time_assert_, __LINE__) \
   { char a[(assertion) ? 1 : -1]; }

 This trick won't work if VERIFY is used in two different files with
 the same line number.  Typically the problem would occur if there are
 multiple headers that use VERIFY, or a header and a source file that
 both use VERIFY.

That's true, but maybe it won't matter in practice?
All of my uses of the statement-form have ended up being
expanded in .c files.

 Admittedly it's a bit of a pain to have to come up with a name for
 each requirement, as is the case with mktime.c now.

 So, how about if we simply dump the named-requirement variant, and
 stick only with the unnamed variant?  If there is a need to verify
 stuff at the top level, we can do something like this:

 static inline void
 verify_mktime_requirements (void)
 {
   verify (TYPE_IS_INTEGER (time_t));
   verify (TYPE_TWOS_COMPLEMENT (int));
   ...
 }

That still requires coming up with a name: the function name.
I want something so that my recent patch to ls.c (below)
stays concise and continues to work.

Why not continue on with two macros?
If someone tries to use the statement form but cannot
because of a conflict, they can then resort to choosing
a name and adding a static inline function.

 (The inline is to pacify GCC so that it doesn't warn about the
 unused function.)

 One other thought: assert uses lower-case letters, and I'd
 like verify to do so too.

Sure.  Lower case does look better.

 So, how about the following macro instead?

 /* Verify REQUIREMENT at compile-time, as an expression.
Unlike assert, there is no run-time overhead.
Return void.  */
 #define verify(requirement) \
   ((void) sizeof (struct { char a[(requirement) ? 1 : -1]; }))

Index: src/ls.c
===
RCS file: /fetish/cu/src/ls.c,v
retrieving revision 1.390
retrieving revision 1.391
diff -u -p -u -1 -r1.390 -r1.391
--- src/ls.c29 Jun 2005 10:03:10 -  1.390
+++ src/ls.c30 Jun 2005 16:47:58 -  1.391
@@ -500,2 +499,3 @@ static enum indicator_style const indica
 };
+ARGMATCH_VERIFY (indicator_style_args, indicator_style_types);
 
@@ -797,2 +796,3 @@ static enum format const format_types[] 
 };
+ARGMATCH_VERIFY (format_args, format_types);
 
@@ -807,2 +806,3 @@ static enum sort_type const sort_types[]
 };
+ARGMATCH_VERIFY (sort_args, sort_types);
 
@@ -817,2 +816,3 @@ static enum time_type const time_types[]
 };
+ARGMATCH_VERIFY (time_args, time_types);
 
@@ -832,2 +831,3 @@ static enum color_type const color_types
 };
+ARGMATCH_VERIFY (color_args, color_types);
 


___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib