Re: new gnulib module "verify" for compile-time assertions

[Jim Meyering]

I wrote:
> Bruno Haible <[EMAIL PROTECTED]> wrote:
>> Paul Eggert wrote:
>>> I suspect it may not be the last word, with all
>>> these screwy compilers to test).
>>
>> Indeed, IRIX 6.5 cc gives "warning: signed bitfield of length 1".
>>
>> Changing the verify_type__ macro like this makes it work without warning.
>>
>> # define verify_type__(R) \
>> struct { int verify_error_if_negative_size__ : (R) ? 2 : -1; }
>
> Or just make the bitfield use type `unsigned int'.
> Then people won't wonder why we used 2 instead of 1,
> and we won't have to worry about documenting it, either.

I checked this in:

2005-09-24  Jim Meyering  <[EMAIL PROTECTED]>

* verify.h (verify_type__): Use `unsigned int' as the bitfield type
so we can once again use a positive bitfield width of 1 -- now we
don't have to explain why we were using a bitfield width of 2.


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

Re: new gnulib module "verify" for compile-time assertions

[Jim Meyering]

Bruno Haible <[EMAIL PROTECTED]> wrote:

> Paul Eggert wrote:
>> I suspect it may not be the last word, with all
>> these screwy compilers to test).
>
> Indeed, IRIX 6.5 cc gives "warning: signed bitfield of length 1".
>
> Changing the verify_type__ macro like this makes it work without warning.
>
> # define verify_type__(R) \
> struct { int verify_error_if_negative_size__ : (R) ? 2 : -1; }

Or just make the bitfield use type `unsigned int'.
Then people won't wonder why we used 2 instead of 1,
and we won't have to worry about documenting it, either.

# define verify_type__(R) \
struct { unsigned int verify_error_if_negative_size__ : (R) ? 1 : -1; }
>
> Other than that, it works fine with AIX xlc, IRIX cc, HP-UX cc, OSF/1 4.0 cc.

Thanks for testing it.


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

Re: [bug-gnulib] Re: new gnulib module "verify" for compile-time assertions

[Paul Eggert]

Bruno Haible <[EMAIL PROTECTED]> writes:

> Changing the verify_type__ macro like this makes it work without warning.
>
> # define verify_type__(R) \
> struct { int verify_error_if_negative_size__ : (R) ? 2 : -1; }

Thanks.  I installed that.

I'm thinking of talking about verify.h in my programming language
class, as an example of how tricky real-world language-lawyering can
get when you're trying to solve what ought to be a trivial task.
Perhaps I can scare a few more students into taking ML and Smalltalk
seriously.  (On the other hand, could one even write the equivalent of
verify.h in ML and Smalltalk?)


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

Re: Using regex on OS/X

[Paul Eggert]

James Gallagher <[EMAIL PROTECTED]> writes:

> Please let me know when the fix is in CVS or if you'd like me to
> submit a patch.

OK, I've installed this into both gnulib and coreutils.  The long list is
awkward

2005-09-23  Paul Eggert  <[EMAIL PROTECTED]>

* regex.m4 (gl_REGEX): If replacing, define regcomp to rpl_regcomp,
and similarly for the other external symbols.  Problem reported
by James Gallager.

--- regex.m49 Sep 2005 21:07:50 -   1.40
+++ regex.m423 Sep 2005 21:17:57 -  1.41
@@ -1,4 +1,4 @@
-#serial 29
+#serial 30
 
 # Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2004, 2005 Free
 # Software Foundation, Inc.
@@ -120,6 +120,36 @@ AC_DEFUN([gl_REGEX],
   esac
 
   if test $ac_use_included_regex = yes; then
+AC_DEFINE([re_syntax_options], [rpl_re_syntax_options],
+  [Define to rpl_re_syntax_options if the replacement should be used.])
+AC_DEFINE([re_set_syntax], [rpl_re_set_syntax],
+  [Define to rpl_re_set_syntax if the replacement should be used.])
+AC_DEFINE([re_compile_pattern], [rpl_re_compile_pattern],
+  [Define to rpl_re_compile_pattern if the replacement should be used.])
+AC_DEFINE([re_compile_fastmap], [rpl_re_compile_fastmap],
+  [Define to rpl_re_compile_fastmap if the replacement should be used.])
+AC_DEFINE([re_search], [rpl_re_search],
+  [Define to rpl_re_search if the replacement should be used.])
+AC_DEFINE([re_search_2], [rpl_re_search_2],
+  [Define to rpl_re_search_2 if the replacement should be used.])
+AC_DEFINE([re_match], [rpl_re_match],
+  [Define to rpl_re_match if the replacement should be used.])
+AC_DEFINE([re_match_2], [rpl_re_match_2],
+  [Define to rpl_re_match_2 if the replacement should be used.])
+AC_DEFINE([re_set_registers], [rpl_re_set_registers],
+  [Define to rpl_re_set_registers if the replacement should be used.])
+AC_DEFINE([re_comp], [rpl_re_comp],
+  [Define to rpl_re_comp if the replacement should be used.])
+AC_DEFINE([re_exec], [rpl_re_exec],
+  [Define to rpl_re_exec if the replacement should be used.])
+AC_DEFINE([regcomp], [rpl_regcomp],
+  [Define to rpl_regcomp if the replacement should be used.])
+AC_DEFINE([regexec], [rpl_regexec],
+  [Define to rpl_regexec if the replacement should be used.])
+AC_DEFINE([regerror], [rpl_regerror],
+  [Define to rpl_regerror if the replacement should be used.])
+AC_DEFINE([regfree], [rpl_regfree],
+  [Define to rpl_regfree if the replacement should be used.])
 AC_LIBOBJ([regex])
 gl_PREREQ_REGEX
   fi


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

Re: exclude.c build failure with some sunstudio compiler

[Jim Meyering]

Paul Eggert <[EMAIL PROTECTED]> wrote:
>> Probably due to differing prototypes.
>> Do you think it's worth adding a cast or two?
>
> How about if we instead detect the implementation bug and use our own
> fnmatch?  I installed this -- does it fix the problem?

Much better.  Shame on me for suggesting casts :-)
Your patch does indeed solve the build failure.

> 2005-09-23  Paul Eggert  <[EMAIL PROTECTED]>
>
>   * m4/fnmatch.m4 (_AC_FUNC_FNMATCH_IF): Catch Sun Studio 10u1 on Linux
>   bug reported by Jim Meyering.


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

Re: [bug-gnulib] Re: new gnulib module "verify" for compile-time assertions

[Bruno Haible]

Paul Eggert wrote:
> I suspect it may not be the last word, with all
> these screwy compilers to test).

Indeed, IRIX 6.5 cc gives "warning: signed bitfield of length 1".

Changing the verify_type__ macro like this makes it work without warning.

# define verify_type__(R) \
struct { int verify_error_if_negative_size__ : (R) ? 2 : -1; }


Other than that, it works fine with AIX xlc, IRIX cc, HP-UX cc, OSF/1 4.0 cc.

Bruno



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

Re: exclude.c build failure with some sunstudio compiler

[Paul Eggert]

Jim Meyering <[EMAIL PROTECTED]> writes:

> On an x86_64 linux 2.6.9 system with
> CC=/usr/local/sys/sunstudio/sunstudio10u1/bin/cc
>
>   HOST=abajo.math.utah.edu
>   HOSTTYPE=x86_64-linux
>
> I see this build failure:
>
> /usr/local/sys/sunstudio/sunstudio10u1/bin/cc -DHAVE_CONFIG_H 
> -DLIBDIR=\"/usr/loc
> al/lib\" -I. -I. -I..  -I.. -I.   -g -c exclude.c
> "/usr/include/fnmatch.h", line 30: warning: macro redefined: __const
> "exclude.c", line 164: operands have incompatible types:
>  pointer to function(pointer to char, pointer to char, int) returning 
> int
>  ":" pointer to function(pointer to const char, pointer to const char, int) 
> retur
> ning int
> "exclude.c", line 164: warning: assignment type mismatch:
> pointer to function(pointer to const char, pointer to const char, 
> int) re
> turning int "=" pointer to function(pointer to char, pointer to char, int) 
> return
> ing int
> cc: acomp failed for exclude.c
> make[3]: *** [exclude.o] Error 2
>
> Probably due to differing prototypes.
> Do you think it's worth adding a cast or two?

How about if we instead detect the implementation bug and use our own
fnmatch?  I installed this -- does it fix the problem?

2005-09-23  Paul Eggert  <[EMAIL PROTECTED]>

* m4/fnmatch.m4 (_AC_FUNC_FNMATCH_IF): Catch Sun Studio 10u1 on Linux
bug reported by Jim Meyering.

--- m4/fnmatch.m4   23 Jan 2005 08:06:57 -  1.19
+++ m4/fnmatch.m4   23 Sep 2005 20:26:33 -  1.21
@@ -3,7 +3,8 @@
 # This is a modified version of autoconf's AC_FUNC_FNMATCH.
 # This file should be simplified after Autoconf 2.57 is required.
 
-# Copyright (C) 2000, 2001, 2002, 2003, 2004 Free Software Foundation, Inc.
+# Copyright (C) 2000, 2001, 2002, 2003, 2004, 2005 Free Software
+# Foundation, Inc.
 # This file is free software; the Free Software Foundation
 # gives unlimited permission to copy and/or distribute it,
 # with or without modifications, as long as this notice is preserved.
@@ -27,9 +28,15 @@ AC_DEFUN([_AC_FUNC_FNMATCH_IF],
 # include 
 # define y(a, b, c) (fnmatch (a, b, c) == 0)
 # define n(a, b, c) (fnmatch (a, b, c) == FNM_NOMATCH)
+  static int
+  fnm (char const *pattern, char const *string, int flags)
+  {
+return fnmatch (pattern, string, flags);
+  }
  ],
 [exit
-  (!(y ("a*", "abc", 0)
+  (!((fnm ? fnm : fnmatch) ("a*", "", 0) == FNM_NOMATCH
+ && y ("a*", "abc", 0)
  && n ("d*/*1", "d/s/1", FNM_PATHNAME)
  && y ("abc", "abc", 0)
  && n ("abc", "abc", FNM_NOESCAPE)



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

Re: getaddrinfo needs socklen, sync from coreutils

[Jim Meyering]

Paul Eggert <[EMAIL PROTECTED]> wrote:

> Bruno Haible <[EMAIL PROTECTED]> writes:
>
>> This is redundant. The module dependency from 'getaddrinfo' to 'socklen'
>> already implies that gl_SOCKLEN_T must be invoked from configure.ac,
>> directly or indirectly. No need to repeat the module dependencies in the
>> *.m4 files.
>
> Right you are.  I undid the change to m4/getaddrinfo.m4 (in both
> gnulib and coreutils).
>
> I also installed into gnulib the getaddrinfo.c patch mentioned in
> 
> since it is related to the getaddrinfo.m4 patch, is just a bugfix
> patch, and nobody has objected.

Thanks to both of you.
I've also done this for coreutils:

* jm-macros.m4 (gl_MACROS): AC_REQUIRE([gl_SOCKLEN_T]) here,
now that it's no longer required by getaddrinfo.m4.


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

Re: [bug-gnulib] getaddrinfo needs socklen, sync from coreutils

[Paul Eggert]

Bruno Haible <[EMAIL PROTECTED]> writes:

> This is redundant. The module dependency from 'getaddrinfo' to 'socklen'
> already implies that gl_SOCKLEN_T must be invoked from configure.ac,
> directly or indirectly. No need to repeat the module dependencies in the
> *.m4 files.

Right you are.  I undid the change to m4/getaddrinfo.m4 (in both
gnulib and coreutils).

I also installed into gnulib the getaddrinfo.c patch mentioned in

since it is related to the getaddrinfo.m4 patch, is just a bugfix
patch, and nobody has objected.


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

utimens port to Solaris 10

[Paul Eggert]

I installed the following into both gnulib and coreutils, to port the
utimens module to Solaris 10, which has yet another primitive for
setting file time stamps (and yet another primitive that can't do it
to full resolution! When will these guys learn?).

2005-09-23  Paul Eggert  <[EMAIL PROTECTED]>

* lib/utimens.c (futimens): Use futimesat if available.
Prefer it to futimes since it doesn't have the futimes bug.
* m4/utimens.m4 (gl_UTIMENS): Check for futimesat.

Index: lib/utimens.c
===
RCS file: /cvsroot/gnulib/gnulib/lib/utimens.c,v
retrieving revision 1.4
diff -p -u -r1.4 utimens.c
--- lib/utimens.c   14 May 2005 06:03:58 -  1.4
+++ lib/utimens.c   23 Sep 2005 19:14:59 -
@@ -25,6 +25,7 @@
 #include "utimens.h"
 
 #include 
+#include 
 
 #if HAVE_UTIME_H
 # include 
@@ -61,7 +62,7 @@ futimens (int fd ATTRIBUTE_UNUSED,
   /* There's currently no interface to set file timestamps with
  nanosecond resolution, so do the best we can, discarding any
  fractional part of the timestamp.  */
-#if HAVE_WORKING_UTIMES
+#if HAVE_FUTIMESAT || HAVE_WORKING_UTIMES
   struct timeval timeval[2];
   struct timeval const *t;
   if (timespec)
@@ -74,7 +75,11 @@ futimens (int fd ATTRIBUTE_UNUSED,
 }
   else
 t = NULL;
-# if HAVE_FUTIMES
+
+# if HAVE_FUTIMESAT
+  return fd < 0 ? futimesat (AT_FDCWD, file, t) : futimesat (fd, NULL, t);
+# else
+#  if HAVE_FUTIMES
   if (0 <= fd)
 {
   if (futimes (fd, t) == 0)
@@ -92,8 +97,9 @@ futimens (int fd ATTRIBUTE_UNUSED,
  return -1;
}
 }
-# endif
+#  endif
   return utimes (file, t);
+# endif
 
 #else
 
Index: m4/utimens.m4
===
RCS file: /cvsroot/gnulib/gnulib/m4/utimens.m4,v
retrieving revision 1.4
diff -p -u -r1.4 utimens.m4
--- m4/utimens.m4   21 Mar 2005 22:06:27 -  1.4
+++ m4/utimens.m4   23 Sep 2005 19:14:59 -
@@ -13,5 +13,5 @@ AC_DEFUN([gl_UTIMENS],
   AC_REQUIRE([gl_FUNC_UTIMES])
   AC_REQUIRE([gl_CHECK_TYPE_STRUCT_TIMESPEC])
   AC_REQUIRE([gl_CHECK_TYPE_STRUCT_UTIMBUF])
-  AC_CHECK_FUNCS_ONCE(futimes)
+  AC_CHECK_FUNCS_ONCE([futimes futimesat])
 ])


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

Re: new gnulib module "verify" for compile-time assertions

[Jim Meyering]

Paul Eggert <[EMAIL PROTECTED]> wrote:
...
> How about the following patch instead?  I installed it in gnulib and
> coreutils (though I suspect it may not be the last word, with all
> these screwy compilers to test).
>
> 2005-09-23  Paul Eggert  <[EMAIL PROTECTED]>
>
>   * verify.h (GL_CONCAT0, GL_CONCAT): Remove.
>   (verify): Don't use the __LINE__ trick, as it doesn't work in general.
>   Instead, declare a function that returns a pointer to an array,
>   and use verify_type__ to declare the size of the array.
>   Problem and germ of a solution reported by Bruno Haible.
...
>  # define verify(R) \
> -extern verify_type__ (R) GL_CONCAT (verify_function_, __LINE__) (void)
> +extern int (* verify_function__ (void)) [sizeof (verify_type__ (R))]

Clever!
I hope it works.


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

Re: new gnulib module "verify" for compile-time assertions

[Paul Eggert]

Bruno Haible <[EMAIL PROTECTED]> writes:

> If we can get away without this restriction, we should.

I agree, but like Jim I'd rather avoid the Autoconf test if we can.

How about the following patch instead?  I installed it in gnulib and
coreutils (though I suspect it may not be the last word, with all
these screwy compilers to test).

2005-09-23  Paul Eggert  <[EMAIL PROTECTED]>

* verify.h (GL_CONCAT0, GL_CONCAT): Remove.
(verify): Don't use the __LINE__ trick, as it doesn't work in general.
Instead, declare a function that returns a pointer to an array,
and use verify_type__ to declare the size of the array.
Problem and germ of a solution reported by Bruno Haible.

--- verify.h22 Sep 2005 22:56:29 -  1.1
+++ verify.h23 Sep 2005 17:52:49 -  1.3
@@ -21,34 +21,23 @@
 #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 if 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.  */
+/* Each of these macros verifies that its argument R is a nonzero
+   constant expression.  To be portable, R's type must be integer (or
+   boolean).  Unlike assert, there is no run-time overhead.  */
+
+/* A type that is valid if and only if R is a nonzero constant expression.
+   The symbols verify_type__ and verify_error_if_negative_size__ 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.  */
+/* Verify requirement R at compile-time, as a declaration.  */
 
 # define verify(R) \
-extern verify_type__ (R) GL_CONCAT (verify_function_, __LINE__) (void)
+extern int (* verify_function__ (void)) [sizeof (verify_type__ (R))]
 
 /* 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.  */
 


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

Re: [bug-gnulib] getaddrinfo needs socklen, sync from coreutils

[Bruno Haible]

Jim Meyering wrote:
>  # Prerequisites of lib/getaddrinfo.h and lib/getaddrinfo.c.
>  AC_DEFUN([gl_PREREQ_GETADDRINFO], [
> +  AC_REQUIRE([gl_SOCKLEN_T])
>AC_REQUIRE([gl_C_RESTRICT])
>AC_REQUIRE([gl_SOCKET_FAMILIES])

This is redundant. The module dependency from 'getaddrinfo' to 'socklen'
already implies that gl_SOCKLEN_T must be invoked from configure.ac,
directly or indirectly. No need to repeat the module dependencies in the
*.m4 files.

Bruno



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

Re: Using regex on OS/X

[James Gallagher]

Yes, that does fix the problem.

Please let me know when the fix is in CVS or if you'd like me to submit 
a patch.


Thanks.

On Sep 22, 2005, at 11:16 PM, Paul Eggert wrote:


James Gallagher <[EMAIL PROTECTED]> writes:


g++ -I./GNU -g -O2 -o getdap getdap.o -Wl,-bind_at_load
./.libs/libdap.a -L/usr/local/lib /usr/local/lib/libcurl.dylib -lssl
-lcrypto /usr/local/lib/libxml2.dylib -ldl -lz /usr/lib/libiconv.dylib
-lm -lpthread
ld: warning multiple definitions of symbol _regcomp
./.libs/libdap.a(regex.o) definition of _regcomp in section
(__TEXT,__text)
/usr/lib/libdl.dylib(regcomp.So) definition of _regcomp


Does it fix things if you put

#define regcomp rpl_regcomp

into config.h, and similarly for regexec and regfree?  If so, we
should probably modify regex.m4 to do that.


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



--
James Gallagherjgallagher at opendap.org
OPeNDAP, Inc   406.723.8663



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

getaddrinfo needs socklen, sync from coreutils

[Jim Meyering]

I've just discovered/fixed a build problem with the getaddrinfo module.
It didn't depend on the socklen module (for the declaration of socklen_t).
So I've merged these changes from coreutils:

2005-09-23  Jim Meyering  <[EMAIL PROTECTED]>

* modules/getaddrinfo (Depends-on): Add socklen.

2005-09-23  Jim Meyering  <[EMAIL PROTECTED]>

Sync from coreutils.
Correct build failure (socklen_t not defined) on at least
mips-sgi-irix6.5 and alphaev67-dec-osf5.1.
* getaddrinfo.m4 (gl_PREREQ_GETADDRINFO): Require gl_SOCKLEN_T.

2005-09-22  Paul Eggert  <[EMAIL PROTECTED]>

Sync from coreutils.
* getaddrinfo.m4 (gl_PREREQ_GETADDRINFO): Check for netinet/in.h.

Index: modules/getaddrinfo
===
RCS file: /cvsroot/gnulib/gnulib/modules/getaddrinfo,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -p -u -r1.4 -r1.5
--- modules/getaddrinfo 13 Sep 2005 04:15:15 -  1.4
+++ modules/getaddrinfo 23 Sep 2005 15:48:18 -  1.5
@@ -11,6 +11,7 @@ m4/sockpfaf.m4
 Depends-on:
 restrict
 gettext-h
+socklen
 stdbool
 strdup
 
Index: m4/getaddrinfo.m4
===
RCS file: /cvsroot/gnulib/gnulib/m4/getaddrinfo.m4,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -p -u -r1.4 -r1.5
--- m4/getaddrinfo.m4   13 Sep 2005 04:15:15 -  1.4
+++ m4/getaddrinfo.m4   23 Sep 2005 15:49:05 -  1.5
@@ -1,5 +1,5 @@
-# getaddrinfo.m4 serial 3
-dnl Copyright (C) 2004 Free Software Foundation, Inc.
+# getaddrinfo.m4 serial 5
+dnl Copyright (C) 2004, 2005 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
 dnl with or without modifications, as long as this notice is preserved.
@@ -13,7 +13,9 @@ AC_DEFUN([gl_GETADDRINFO],
 
 # Prerequisites of lib/getaddrinfo.h and lib/getaddrinfo.c.
 AC_DEFUN([gl_PREREQ_GETADDRINFO], [
+  AC_REQUIRE([gl_SOCKLEN_T])
   AC_REQUIRE([gl_C_RESTRICT])
   AC_REQUIRE([gl_SOCKET_FAMILIES])
   AC_REQUIRE([AC_C_INLINE])
+  AC_CHECK_HEADERS_ONCE([netinet/in.h])
 ])


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

Re: new gnulib module "verify" for compile-time assertions

[Jim Meyering]

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.
>>
>> 
>
> 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

Re: new gnulib module "verify" for compile-time assertions

[Bruno Haible]

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.
>
> 

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.

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.

Bruno


diff -c -3 -r1.1 verify.h
*** lib/verify.h22 Sep 2005 22:56:29 -  1.1
--- lib/verify.h23 Sep 2005 14:02:23 -
***
*** 16,22 
 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
--- 16,22 
 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, Jim Meyering, Bruno Haible.  */
  
  #ifndef VERIFY_H
  # define VERIFY_H 1
***
*** 24,31 
  # define GL_CONCAT0(x, y) x##y
  # define GL_CONCAT(x, y) GL_CONCAT0 (x, y)
  
! /* A type that is valid if and only if 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.  */
  
--- 24,33 
  # define GL_CONCAT0(x, y) x##y
  # define GL_CONCAT(x, y) GL_CONCAT0 (x, y)
  
! /* A type that is valid if and only if R is a constant expression with nonzero
!value.
!R should be a boolean or integer expression.
!Verify that R is a constant expression and that R evaluates to true.
 verify_type__ and verify_error_if_negative_size__ are symbols that
 are private to this header file.  */
  
***
*** 34,57 
  
  /* 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) ((verify_type__ (R) *) 0))
  
  #endif
--- 36,70 
  
  /* Verify requirement R at compile-time, as a declaration.
 R should be an integer constant expression.
!Unlike assert, there is no run-time overhead.  */
  
! # if !HAVE_VARIABLE_SIZE_ARRAYS
!/* This variant is fully portable to all compilers that reject variable-
!   size array types.  Using __LINE__ is optional; it only serves to
!   get prettier error messages after the first error with Solaris cc.  */
! #  define verify(R) \
!  extern int (* GL_CONCAT (verify_function_, __LINE__) (void)) \
! [(R) ? 1 : -1]
! # elif __GNUC__ > 2 || (__GNUC__ == 2 && __GNUC_MINOR__ >= 90)
!/* This variant is specific to GNU C and avoids a gcc warning
!   "anonymous struct declared inside parameter list".  */
! #  define verify(R) \
!  extern int (* verify_function__ (void)) \
! [__builtin_constant_p ((R)) ? ((R) ? 1 : -1) : -1]
! # else
!/* This variant is fully portable but may generate warnings.  */
! #  define verify(R) \
!  extern void verify_function__ (int [sizeof (verify_type__ (R))])
! # endif
  
  /* Verify requirement R at compile-time, as an expression.
!R should be an boolean or integer expression.
!Verify that R is a constant expression and that R evaluates to true.
 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) (verify_type__ (R) *) 

Re: bug in getaddrinfo module

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Paul Eggert on 9/22/2005 11:14 PM:
> Thanks for reporting that.  Aside from the missing 
> that you mentioned, I noticed a few other glitches.
> 
> I installed the following fix into coreutils; does it fix things for
> you?  If so, it should be propagated into gnulib.

Works fine.  Thanks for the quick fix.

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDNAAx84KuGfSFAYARAonzAJ9/OfsWJye2/j2kUCucGRzWXyGTtwCcDyyQ
I9oCpvNXJQjGVFqUEZsJXRI=
=4DXP
-END PGP SIGNATURE-


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

Re: [bug-gnulib] Redundant AC_LIBSOURCES calls

[Stepan Kasal]

Hello,

On Fri, Sep 23, 2005 at 02:37:06PM +0200, Bruno Haible wrote:
> Stepan Kasal wrote:
> > But in the basic case, when only the implementation is fixed and no
> > header is needed, I see no advantage in adding a redundant call to
> > AC_LIBSOURCES.
> 
> The advantage is simplicity and consistency.

I thought you would object...  ;-)

It's only a matter of style and preferrence, no big deal.

> Your approach is even worse: It forces the maintainer to look or grep
> for AC_LIBOBJ invocations in the autoconf macros. And not only in the
> package's *.m4 files, but also in autoconf's and automake's own *.m4 files!
> It opens the door to problems that will appear with one version of autoconf
> and not with another...
> 
> Too much magic -> implies -> too much complexity when debugging.

The magic is already there: AC_LIBOBJ calls AC_LIBSOURCE since 2.50 when it
was introduced.  I don't see any chance to remove it now.

This magic can complicate debugging, yes.  Even though gnulib uses the
redundant style, the magic is still hidden behind, ready to bite you!

OK, forget about it.

Stepan


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

Re: [bug-gnulib] Redundant AC_LIBSOURCES calls

[Bruno Haible]

Stepan Kasal wrote:
> But in the basic case, when only the implementation is fixed and no
> header is needed, I see no advantage in adding a redundant call to
> AC_LIBSOURCES.

The advantage is simplicity and consistency.

In an ideal world, all source files are listed in Makefile.am. Very simple,
consistent, and makes it very easy to debug problems that might appear
with "make dist".

The approach to use AC_LIBSOURCES for all source files, is already worse
because
  - it mixes autoconfiguration issues and pathname issues,
  - it assumes a transfer of information from a *.m4 file to a *.am file
which automake does not implement in with sufficient generality.
But at least, it can be consistent, and if every gnulib module has a .m4
file with AC_LIBSOURCES invocations for all source files, you know where
to look when problems appear during "make dist".

Your approach is even worse: It forces the maintainer to look or grep
for AC_LIBOBJ invocations in the autoconf macros. And not only in the
package's *.m4 files, but also in autoconf's and automake's own *.m4 files!
It opens the door to problems that will appear with one version of autoconf
and not with another...

Too much magic -> implies -> too much complexity when debugging.

Keep it simple! Even if some things are then redundant.

Bruno



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

Re: new gnulib module "verify" for compile-time assertions

[Jim Meyering]

Bruno Haible <[EMAIL PROTECTED]> wrote:
> Paul Eggert wrote:
>> The first step is to add a new module "verify", which defines macros
>> verify(EXPR) and verify_expr(EXPR) that act like assert(EXPR) except
>> they check EXPR at compile-time, not at run-time.  verify(EXPR) is for
>> declaration contexts, and verify_expr is for expression contexts.
>
> Thanks a lot for making this generally available!
>
> At first sight, using a bitfield width instead of an array size, to
> avoid multiple-definition errors, seems awfully cool. But it does not
> work:

Hi Bruno,

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.

> $ cat foo.c
> #include "verify.h"
> verify (1 + 1 == 2); verify (1 + 1 == 2);
> $ gcc -O -c foo.c
> foo.c:2: conflicting types for `verify_function_2'
> foo.c:2: previous declaration of `verify_function_2'

True, this causes a problem, but it's easily avoidable.
Just don't use verify twice on the same line.
If you must have two on a line (e.g., in a macro), then use verify_expr,
assuming that's possible.

If for some reason it's important to have two on a line, we can revert
to verify.c version 1.6 in coreutils' CVS.



That earlier incarnation of this macro used gcc's __builtin_constant_p
instead, but of course, that clause was effective only for gcc.
But considering the non-diagnosis of misuse was possible mainly with
gcc (few other compilers allow a parameter to be used as an automatic array
dimension), it's appropriate that the check for that is also gcc-specific.

Jim


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

Redundant AC_LIBSOURCES calls

[Stepan Kasal]

Hello,

I propose the patch attached below; an explanation follows:

I think that when AC_LIBOBJ and friends was designed, the idea was
to use
some testing
if foo_is_broken; then
AC_LIBOBJ([foo])
fi

The AC_LISOURCE/AC_LIBSOURCES macros were also made visible, so that
the user can name additional sources, when necessary.

Actually, gnulib needs foo.h in most cases, because the module fixes
also a broken declaration, not only broken implementation.

But in the basic case, when only the implementation is fixed and no
header is needed, I see no advantage in adding a redundant call to
AC_LIBSOURCES.

Have a nice day,
Stepan Kasal
2005-09-23  Stepan Kasal  <[EMAIL PROTECTED]>

* m4/gettime.m4, m4/getugroups.m4, m4/idcache.m4, m4/inttostr.m4,
  m4/nanosleep.m4, m4/settime.m4: Remove redundant AC_LIBSOURCES.

Index: m4/gettime.m4
===
RCS file: /cvsroot/gnulib/gnulib/m4/gettime.m4,v
retrieving revision 1.4
diff -u -r1.4 gettime.m4
--- m4/gettime.m4   26 Feb 2005 08:18:27 -  1.4
+++ m4/gettime.m4   23 Sep 2005 09:57:45 -
@@ -6,7 +6,6 @@
 
 AC_DEFUN([gl_GETTIME],
 [
-  AC_LIBSOURCES([gettime.c])
   AC_LIBOBJ([gettime])
 
   dnl Prerequisites of lib/gettime.c.
Index: m4/getugroups.m4
===
RCS file: /cvsroot/gnulib/gnulib/m4/getugroups.m4,v
retrieving revision 1.4
diff -u -r1.4 getugroups.m4
--- m4/getugroups.m421 Mar 2005 22:06:27 -  1.4
+++ m4/getugroups.m423 Sep 2005 09:57:45 -
@@ -6,7 +6,6 @@
 
 AC_DEFUN([gl_GETUGROUPS],
 [
-  AC_LIBSOURCES([getugroups.c])
   AC_LIBOBJ([getugroups])
 
   dnl Prerequisites of lib/getugroups.c.
Index: m4/idcache.m4
===
RCS file: /cvsroot/gnulib/gnulib/m4/idcache.m4,v
retrieving revision 1.4
diff -u -r1.4 idcache.m4
--- m4/idcache.m4   21 Mar 2005 22:06:27 -  1.4
+++ m4/idcache.m4   23 Sep 2005 09:57:45 -
@@ -6,7 +6,6 @@
 
 AC_DEFUN([gl_IDCACHE],
 [
-  AC_LIBSOURCES([idcache.c])
   AC_LIBOBJ([idcache])
 
   dnl Prerequisites of lib/idcache.c.
Index: m4/inttostr.m4
===
RCS file: /cvsroot/gnulib/gnulib/m4/inttostr.m4,v
retrieving revision 1.4
diff -u -r1.4 inttostr.m4
--- m4/inttostr.m4  21 Mar 2005 22:06:27 -  1.4
+++ m4/inttostr.m4  23 Sep 2005 09:57:45 -
@@ -8,11 +8,6 @@
 [
   AC_LIBSOURCES([inttostr.c, inttostr.h, intprops.h])
 
-  dnl We don't technically need to list the following .c files, since their
-  dnl functions are named in the AC_LIBOBJ calls, but this is an unusual
-  dnl module and it seems a little clearer to do so.
-  AC_LIBSOURCES([imaxtostr.c, offtostr.c, umaxtostr.c])
-
   AC_LIBOBJ([imaxtostr])
   AC_LIBOBJ([offtostr])
   AC_LIBOBJ([umaxtostr])
Index: m4/nanosleep.m4
===
RCS file: /cvsroot/gnulib/gnulib/m4/nanosleep.m4,v
retrieving revision 1.20
diff -u -r1.20 nanosleep.m4
--- m4/nanosleep.m4 2 May 2005 07:00:50 -   1.20
+++ m4/nanosleep.m4 23 Sep 2005 09:57:45 -
@@ -12,8 +12,6 @@
 
 AC_DEFUN([gl_FUNC_NANOSLEEP],
 [
- AC_LIBSOURCES([nanosleep.c])
-
  nanosleep_save_libs=$LIBS
 
  # Solaris 2.5.1 needs -lposix4 to get the nanosleep function.
Index: m4/settime.m4
===
RCS file: /cvsroot/gnulib/gnulib/m4/settime.m4,v
retrieving revision 1.4
diff -u -r1.4 settime.m4
--- m4/settime.m4   21 Mar 2005 22:06:27 -  1.4
+++ m4/settime.m4   23 Sep 2005 09:57:45 -
@@ -6,7 +6,6 @@
 
 AC_DEFUN([gl_SETTIME],
 [
-  AC_LIBSOURCES([settime.c])
   AC_LIBOBJ([settime])
 
   dnl Prerequisites of lib/settime.c.
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: regex-0.12's regex.h seems to have a little bug

[Stepan Kasal]

Hello again,

On Fri, Sep 23, 2005 at 10:33:21AM +0200, Stepan Kasal wrote:
> > > I'm afraid we need a design document for the solution.

> Simon, perhaps you could volunteer.

... or you can just wait.  I think I have something in mind now,
and hopefully I'll write it down sometimes next week.

Have a nice day,
Stepan


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

Re: [bug-gnulib] new gnulib module "verify" for compile-time assertions

[Bruno Haible]

Paul Eggert wrote:
> The first step is to add a new module "verify", which defines macros
> verify(EXPR) and verify_expr(EXPR) that act like assert(EXPR) except
> they check EXPR at compile-time, not at run-time.  verify(EXPR) is for
> declaration contexts, and verify_expr is for expression contexts.

Thanks a lot for making this generally available!

At first sight, using a bitfield width instead of an array size, to
avoid multiple-definition errors, seems awfully cool. But it does not
work:

$ cat foo.c
#include "verify.h"
verify (1 + 1 == 2); verify (1 + 1 == 2);
$ gcc -O -c foo.c
foo.c:2: conflicting types for `verify_function_2'
foo.c:2: previous declaration of `verify_function_2'

Here's a fix that makes this work. OK to commit?

Bruno


diff -c -3 -r1.1 verify.h
*** verify.h22 Sep 2005 22:56:29 -  1.1
--- verify.h23 Sep 2005 09:48:54 -
***
*** 16,22 
 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
--- 16,22 
 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, Jim Meyering, Bruno Haible.  */
  
  #ifndef VERIFY_H
  # define VERIFY_H 1
***
*** 26,36 
  
  /* A type that is valid if and only if 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.
--- 26,36 
  
  /* A type that is valid if and only if R is nonzero.
 R should be an integer constant expression.
!verify_array_type__ and verify_pointer_type__ are symbols that are
!private to this header file.  */
  
! # define verify_array_type__(R) int [(R) ? 1 : -1]
! # define verify_pointer_type__(R) int (*) [(R) ? 1 : -1]
  
  /* Verify requirement R at compile-time, as a declaration.
 R should be an integer constant expression.
***
*** 44,50 
 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.
--- 44,50 
 no conforming compiler will reject them outright.  */
  
  # define verify(R) \
! extern void GL_CONCAT (verify_function_, __LINE__) (verify_array_type__ 
(R))
  
  /* Verify requirement R at compile-time, as an expression.
 R should be an integer constant expression.
***
*** 52,57 
 This macro can be used in some contexts where verify cannot, and vice 
versa.
 Return void.  */
  
! # define verify_expr(R) ((void) ((verify_type__ (R) *) 0))
  
  #endif
--- 52,57 
 This macro can be used in some contexts where verify cannot, and vice 
versa.
 Return void.  */
  
! # define verify_expr(R) ((void) ((verify_pointer_type__ (R)) 0))
  
  #endif



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

Re: mingw32 and sockets

[Simon Josefsson]

Bruno Haible <[EMAIL PROTECTED]> writes:

> Simon Josefsson wrote:
>> Would it be possible to create those three POSIX header files if they
>> don't exist on the system, and if winsock2.h do exist?  The created
>> files would simply #include .
>
> Yes, that's the way I would go.

It seems doing that this is not sufficient, the functions doesn't
conform to POSIX behavior.

We could provide replacement functions, perhaps inspired by the
re-implementations in plibc, see
http://cvs.sourceforge.net/viewcvs.py/plibc/plibc/.

However, that sounds like real work, and unpaid Win32 work isn't my
kind of thing, so I'll leave that part for somebody else.  Providing
the POSIX headers seem like good starting point, though, some Win32
functions may be close-enough so that large parts of a program works.
I'll see if the original reporter is interested in carrying on this,
to eventually make GnuTLS built through mingw32 work.  I have no idea
how difficult it would be.

>> Creating them would be done
>> like getopt_.h and others.  The complication is that this has to be
>> done in a sub-directory somehow, so that #include for sys/socket.h
>> works.
>
> Sure. It makes the Makefile.am snippet a little more complicated than for
> the getopt_.h case, because you need a 'distclean-local' rule that does a
> 'rmdir sys'. But then it will work as smoothly as getopt_.h.

Yup.

>> Perhaps this should be considered a mingw32 bug instead?
>
> It would be if the mingw people reach out for POSIX compliance. Do they?

The answer seem to be no.  So ideally, I think the incompatibilities
should be solved by gnulib.

Thanks,
Simon


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

Re: regex-0.12's regex.h seems to have a little bug

[Stepan Kasal]

Hello,

> > I'm afraid we need a design document for the solution.  Then we can
> > implement it.  Have I missed it, or it is yet to be written?
> 
> No, I don't think you've missed it; that work still needs to be done.

but I'm not able to do it.  Simon, perhaps you could volunteer.

Could you please prepare an example project, quickly recap the problem,
explain your needs, and then implement the user side of the solution.
I mean your solution would use no-yet-existent features of Autoconf,
but you'd explain what you are expecting from Autoconf (and Automake).

This would be a form of detailed design document.

Do you have time and interest to do this?

Have a nice day,
Stepan


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