Re: no pthread_spinlock_t on Mac OS 10.6.4

[Paul Eggert]

On 09/20/2010 05:43 PM, Gary V. Vaughan wrote:

> Hmm... looking at gnulib/pthread.h, am I right in assuming that
> threads are now effectively disabled by gnulib on the mac in favour
> of a selection of stub functions?  In which case, I suppose those
> warnings indicate that glthread/lock.c may attempt to call unstubbed
> functions along some codepath and will then crash.

Yes, that's right.  The problem is that the gnulib i18n code includes
pthread.h for its own purposes, and wants primitives that our trivial
pthread replacement doesn't supply.

Could you try the following patch instead?  It tries an idea discussed
earlier today, namely, fall back on mutexes if spinlocks aren't there.
You'll need not only to update lib/pthread.in.h and m4/pthread.m4, but
also to get that code from modules/pthread into your makefile; I did
that by manually editing the "begin gnulib module pthread" section of
lib/gnulib.mk.

The patch below has a chance of working only because the gnulib i18n
code doesn't need spinlocks: if it did, we'd need something fancier.
Perhaps someday there should be a way to tell the i18n code "Hey! This
app doesn't use threads so don't try to include  or link to
the thread library."

Sorry, I can't easily test this as I don't use MacOS.


diff --git a/lib/pthread.in.h b/lib/pthread.in.h
index 0fdf9c3..f8e358b 100644
--- a/lib/pthread.in.h
+++ b/lib/pthread.in.h
@@ -19,6 +19,17 @@
 /* Written by Paul Eggert and Glen Lenker.  */
 
 #ifndef _GL_PTHREAD_H_
+
+#if __GNUC__ >= 3
+...@pragma_system_header@
+#endif
+
+/* The include_next requires a split double-inclusion guard.  */
+#if @HAVE_PTHREAD_H@
+# @INCLUDE_NEXT@ @NEXT_PTHREAD_H@
+#endif
+
+#ifndef _GL_PTHREAD_H_
 #define _GL_PTHREAD_H_
 
 #include 
@@ -27,7 +38,7 @@
 #include 
 #include 
 
-#ifndef HAVE_PTHREAD_T
+#if ! @HAVE_PTHREAD_T@
  typedef int pthread_t;
  typedef int pthread_attr_t;
  typedef int pthread_barrier_t;
@@ -40,9 +51,9 @@
  typedef int pthread_once_t;
  typedef int pthread_rwlock_t;
  typedef int pthread_rwlockattr_t;
- typedef int pthread_spinlock_t;
 #endif
 
+#ifndef PTHREAD_COND_INITIALIZER
 #define PTHREAD_COND_INITIALIZER { 0 }
 #define PTHREAD_MUTEX_INITIALIZER { 0 }
 #define PTHREAD_ONCE_INIT { 0 }
@@ -81,6 +92,9 @@
 
 #define PTHREAD_SCOPE_SYSTEM 0
 #define PTHREAD_SCOPE_PROCESS 1
+#endif
+
+#if ! @HAVE_PTHREAD_T@
 
 /* Provide substitutes for the thread functions that should work
adequately on a single-threaded implementation, where
@@ -147,6 +161,24 @@ pthread_join (pthread_t thread, void **pvalue)
 }
 
 static inline int
+pthread_mutexattr_destroy (pthread_mutexattr_t *attr)
+{
+  return 0;
+}
+
+static inline int
+pthread_mutexattr_init (pthread_mutexattr_t *attr)
+{
+  return 0;
+}
+
+static inline int
+pthread_mutexattr_settype (pthread_mutexattr_t *attr, int attr_type)
+{
+  return 0;
+}
+
+static inline int
 pthread_mutex_destroy (pthread_mutex_t *mutex)
 {
   /* MUTEX is never seriously used.  */
@@ -170,6 +202,12 @@ pthread_mutex_lock (pthread_mutex_t *mutex)
 }
 
 static inline int
+pthread_mutex_trylock (pthread_mutex_t *mutex)
+{
+  return pthread_mutex_lock (mutex);
+}
+
+static inline int
 pthread_mutex_unlock (pthread_mutex_t *mutex)
 {
   /* There is only one thread, so it always unlocks successfully.
@@ -178,40 +216,44 @@ pthread_mutex_unlock (pthread_mutex_t *mutex)
   return 0;
 }
 
+#endif
+
+#if ! @HAVE_PTHREAD_SPINLOCK_T@
+
+/* Approximate spinlocks with mutexes.  */
+
+typedef pthread_mutex_t pthread_spinlock_t;
+
 static inline int
 pthread_spin_init (pthread_spinlock_t *lock, int pshared)
 {
-  /* LOCK is never seriously used.  */
-  return 0;
+  return pthread_mutex_init (lock, NULL);
 }
 
 static inline int
 pthread_spin_destroy (pthread_spinlock_t *lock)
 {
-  /* LOCK is never seriously used.  */
-  return 0;
+  return pthread_mutex_destroy (lock);
 }
 
 static inline int
 pthread_spin_lock (pthread_spinlock_t *lock)
 {
-  /* Only one thread, so it always gets the lock.  */
-  return 0;
+  return pthread_mutex_lock (lock);
 }
 
 static inline int
 pthread_spin_trylock (pthread_spinlock_t *lock)
 {
-  /* Only one thread, so it always gets the lock.  Assume that a
- thread never tries a lock that it already holds.  */
-  return 0;
+  return pthread_mutex_trylock (lock);
 }
 
 static inline int
 pthread_spin_unlock (pthread_spinlock_t *lock)
 {
-  /* Only one thread, so spin locks are no-ops.  */
-  return 0;
+  return pthread_mutex_unlock (lock);
 }
+#endif
 
 #endif /* _GL_PTHREAD_H_ */
+#endif /* _GL_PTHREAD_H_ */
diff --git a/m4/pthread.m4 b/m4/pthread.m4
index 69866cb..2b00944 100644
--- a/m4/pthread.m4
+++ b/m4/pthread.m4
@@ -5,25 +5,50 @@ dnl gives unlimited permission to copy and/or distribute it,
 dnl with or without modifications, as long as this notice is preserved.
 
 AC_DEFUN([gl_PTHREAD_CHECK],
-  [AC_CHECK_HEADERS_ONCE([pthread.h])
+[
+   AC_REQUIRE([gl_PTHREAD_DEFAULTS])
+   AC_CHECK_HEADERS_ONCE([pthread.h])
+   gl_CHECK_NEXT_HEADERS([pthread.h])
+   if test $ac_cv_he

Re: new module 'regex-quote'

[Reuben Thomas]

On 21 September 2010 01:07, Bruno Haible  wrote:
> Reuben,
>
>> Heh. My point precisely: 3 functions and 50 lines versus 1 flag and 5
>> lines (RE_PLAIN) to solve the same problem
>
> I agree that if we had the opportunity to invent regex APIs from scratch
> now, all 4 syntaxes (literals, wildcards, basic regular expression, extended
> regular expression) would be worth supporting equally.
>
> But the fact is that POSIX standardizes the regex API, and therefore there
> is a border between "in glibc" and "outside glibc". Functionality in glibc
> is available at no cost; functionality outside glibc requires additional
> link options and increased startup time or a 50KB bigger executable.

Equally, libc APIs such as the crappy standard string handling
functions waste my time on a daily basis, whereas APIs from other
libraries save it. C does make linking harder than newer languages,
but link options and increased startup time and/or a bigger executable
have never put me off (the penalties are tiny on modern machines),
although I do spend time considering licensing and portability of
libraries I use. Indeed, libc's general weakness in so many areas
means I consider third-party libraries much more often than in other
languages. (glibc is at least better than many libc's in this respect,
by covering a lot more ground, though it is a pity that it carries so
much non-standard crud just for backwards binary compatibility.) In
this particular case, the point is somewhat moot: GNU regex is still
not synced with glibc, many applications continue to use internal
copies unconditionally (though, thanks to hard work by GNU developers,
most GNU programs now use gnulib), and tons of other applications use
other regex libraries altogether.

So, I am not really making things much worse by proposing extensions
to the POSIX API, and indeed I am leaving the door open to make things
better: the chances of any other C regex API ever being standardised
are practically zero, so applications using non-POSIX APIs are always
going to suffer the penalty of an external library; whereas API and
ABI-compatible extensions at least have a chance of one day being
added to the standard.

Not to mention the big picture: the vast majority of C apps these days
use either POSIX or PCRE regex APIs. On most GNU systems, there will
today still be plenty of apps in which POSIX regexes are compiled in
statically via GNU regex (old glibc's and/or old apps). My suggestions
aim at a situation in which, in a few years, the situation is much the
same but the application code is cleaner (and there are not lots of
statically-linked "quote_regexp" functions). And then, a few years
later, the changes get into glibc and the statically linked copies
disappear. Not to mention that plenty of mature programs won't want
any of my extensions, and therefore will not need statically-linked
POSIX regex.

The fundamental point is this: the two scenarios are pretty much equal
with respect to time and space overhead, but evolving standard APIs
over time wins hands down when it comes to improving things for
application programmers, and reducing application code. Developer time
is a much more important resource than machine cycles or bytes, and
that is not to disrespect users, because time that developers save not
coding they can spend on useful optimisation.

(I am also rather alarmed at the way that gnulib seems to be growing
without bound; it should be making bits of itself redundant just as
fast as it can, so that it's the glue between the near past and the
near future, not just another big ball of wax that keeps accreting.)

-- 
http://rrt.sc3d.org

Re: no pthread_spinlock_t on Mac OS 10.6.4

[Bruno Haible]

Hi Paul,

> The problem is that the gnulib i18n code includes pthread.h for its
> own purposes 

I wouldn't call it "the gnulib i18n code". The modules 'lock', 'tls',
etc. are needed by the modules 'strsignal', 'fstrcmp', and 'localename'.
Basically, every piece of code that wants to provide multithreaded
access to a global variable (may it be a registry or cache or anything)
needs locking.

> and wants primitives that our trivial pthread replacement doesn't supply.

Sure, when gnulib provides a "replacement" of a system header, it should
not remove features from the system headers that other parties may rely
upon.

> +   AC_CHECK_TYPES([pthread_t, pthread_spinlock_t])

It would be wise to include  here. Not all systems define
these types in ; some (e.g. mingw pthreads-win32) require
a #include . This include is not part of AC_INCLUDES_DEFAULT.

Bruno

On OpenBSD and if_freenameindex(3).

[Mats Erik Andersson]

Hello,

influenced by an exchange with Simon Josefsson, where we have
on issue with the present matter in GNU Inetutils, I would like
to mention this subject, since GNUlib seems not to resolve the
matter to our satisfaction!

In OpenBSD (definitely in 4.6) there is a POSIX violation,
quoting Simon here, since the header file states

### /usr/include/net/if.h

#define if_freenameindex(x) free(x)

This macro causes difficulties for me in "inetutils/ifconfig/if_index.*".
I am told the POSIX specification demands if_freenameindex(3) to be a
proper function.

Is this situation covered for in GNUlib, or should an increased use of
conditionals on HAVE_STRUCT_IF_NAMEINDEX be the intended way to overcome
this issue?


Best regards,
Mats E A

Re: On OpenBSD and if_freenameindex(3).

[Simon Josefsson]

As an initial response to this problem, I'm installing a self check of
the net/if.h interface.  See below.  Mats, if you could quote the
compiler errors you get when building the self-check below on OpenBSD,
that would be useful.  The next step is to see how gnulib can provide a
replacement that works on various systems.  Perhaps OpenBSD isn't the
only system not working here.

/Simon
>From 3f130a97c39ecb2c388fa34f4123a33c27c66213 Mon Sep 17 00:00:00 2001
From: Simon Josefsson 
Date: Tue, 21 Sep 2010 14:19:58 +0200
Subject: [PATCH] New module to test  interfaces.

---
 ChangeLog|5 +++
 modules/net_if-tests |   10 ++
 tests/test-net_if.c  |   83 ++
 3 files changed, 98 insertions(+), 0 deletions(-)
 create mode 100644 modules/net_if-tests
 create mode 100644 tests/test-net_if.c

diff --git a/ChangeLog b/ChangeLog
index ec48b91..4a62029 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2010-09-21  Simon Josefsson  
+
+	* tests/test-net_if.c: New file.
+	* modules/net_if-tests: New file.
+
 2010-09-20  Paul Eggert  
 
 	pthread: add pthread_spin_destroy
diff --git a/modules/net_if-tests b/modules/net_if-tests
new file mode 100644
index 000..4349e85
--- /dev/null
+++ b/modules/net_if-tests
@@ -0,0 +1,10 @@
+Files:
+tests/test-net_if.c
+
+Depends-on:
+
+configure.ac:
+
+Makefile.am:
+TESTS += test-net_if
+check_PROGRAMS += test-net_if
diff --git a/tests/test-net_if.c b/tests/test-net_if.c
new file mode 100644
index 000..f1cdb99
--- /dev/null
+++ b/tests/test-net_if.c
@@ -0,0 +1,83 @@
+/* Test of  functions.
+   Copyright (C) 2010 Free Software Foundation, Inc.
+
+   This program is free software: you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program.  If not, see .  */
+
+/* Written by Simon Josefsson , 2010.  */
+
+#include 
+#include 
+#include  /* NULL */
+#include  /* printf */
+
+int
+main (int argc, char *argv[])
+{
+  struct if_nameindex ifn, *ifnp, *p;
+  void (*if_fni) (struct if_nameindex *) = if_freenameindex;
+  char *(*if_itn)(unsigned, char *) = if_indextoname;
+  struct if_nameindex  *(*if_ni)(void) = if_nameindex;
+  unsigned (*if_nti)(const char *) = if_nametoindex;
+
+  ifn.if_index = 42;
+  ifn.if_name = "foo";
+
+  p = ifnp = if_nameindex ();
+  if (ifnp == NULL)
+{
+  printf ("if_nameindex returned NULL\n");
+  return 1;
+}
+
+  while (p->if_index)
+{
+  unsigned idx;
+  char buf[IF_NAMESIZE];
+  char *q;
+
+  if (argc > 1)
+printf ("index %d name %s\n", p->if_index, p->if_name);
+
+  idx = if_nametoindex (p->if_name);
+  if (idx != p->if_index)
+{
+  printf ("if_nametoindex (%s) = %d != %d\n",
+  p->if_name, idx, p->if_index);
+  return 1;
+}
+
+  q = if_indextoname (p->if_index, buf);
+  if (q == NULL)
+{
+  printf ("if_indextoname (%d) returned NULL\n", p->if_index);
+  return 1;
+}
+  if (q != buf)
+{
+  printf ("if_indextoname (%d) buffer mismatch?\n", p->if_index);
+  return 1;
+}
+  if (strcmp (p->if_name, q) != 0)
+{
+  printf ("if_indextoname (%s) = %s ?!\n", p->if_name, q);
+  return 1;
+}
+
+  p++;
+}
+
+  if_freenameindex (ifnp);
+
+  return 0;
+}
-- 
1.7.1

Re: Another minor patch to pmccabe2html

[Simon Josefsson]

Reuben Thomas  writes:

> Attached, to make the whitespace in the Makefile.am example more
> copy-and-paste friendly.

Applied, thanks.

> By the way, is there some reason to keep this file and pmccabe.css in
> gnulib rather than push it upstream to pmccabe, and make the gnulib
> module just make the test and suggest an appropriate Makefile.am patch
> with settings for GNU projects?

I don't think there is any particular reason for this.  Is upstream
actively maintained?

/Simon

Re: A fix for pmccabe2html

[Simon Josefsson]

Reuben Thomas  writes:

> On 20 September 2010 15:49, Eric Blake  wrote:
>> Rather than describing the fix, could you post this as a patch?
>
> Sorry; you've made me realise that my habit of not posting patches for
> code I'm not sure about is silly for several reasons.
>
> Patch attached. I've added an Emacs mode-setting line to the top of
> the file so that Emacs gets the right editing mode; is there some
> reason not to have a hash-bang line?

Sounds reasonable to me.  Applied, thanks.

/Simon

Re: Mentions of GSS in gnulib.texi

[Simon Josefsson]

Reuben Thomas  writes:

> Are the mentions of GSS in the section "Out of memory handling" bogus
> cut-and-paste-o's or similar? A bit of googling suggests that the text
> has indeed been cut and pasted from the GNU GSS manual. It seems that
> this section is essentially meant to document xalloc_die (not
> xalloc_fail_func, which is the name this section actually uses).
>
> Should the section be deleted? Rewritten?

It is a cut'n'paste typo.  It could be rewritten or improved.

/Simon

Re: pmccabe2html: more nits; build-aux confusion

[Simon Josefsson]

Reuben Thomas  writes:

> 1. The example Makefile.am code has "lib/" rather than "src/" in the
> path to the source code, even though it's clearly the package source
> that is to be analysed, not the gnulib library code.

This is because it is an example, and the projects I used it for had the
"real" code in lib/ (and the gnulib code in gl/ or similar).  Maybe the
example could be changed to use src/ as that may be more common, but
still, it is an example snippet that needs to be adapted by the
maintainer anyway...

/Simon

Re: Another minor patch to pmccabe2html

[Reuben Thomas]

On 21 September 2010 13:28, Simon Josefsson  wrote:
> Reuben Thomas  writes:
>> By the way, is there some reason to keep this file and pmccabe.css in
>> gnulib rather than push it upstream to pmccabe, and make the gnulib
>> module just make the test and suggest an appropriate Makefile.am patch
>> with settings for GNU projects?
>
> I don't think there is any particular reason for this.  Is upstream
> actively maintained?

It is maintained, although not actively (i.e. the author is accepting
bug fixes &c. but not working on it himself).

I have written to him to ask if he's interested.

-- 
http://rrt.sc3d.org

Re: pmccabe2html: more nits; build-aux confusion

[Reuben Thomas]

On 21 September 2010 13:38, Simon Josefsson  wrote:
> Reuben Thomas  writes:
>
>> 1. The example Makefile.am code has "lib/" rather than "src/" in the
>> path to the source code, even though it's clearly the package source
>> that is to be analysed, not the gnulib library code.
>
> This is because it is an example, and the projects I used it for had the
> "real" code in lib/ (and the gnulib code in gl/ or similar).  Maybe the
> example could be changed to use src/ as that may be more common, but
> still, it is an example snippet that needs to be adapted by the
> maintainer anyway...

Indeed. Maybe src/ is rather commoner as a source directory?

Attached, two patches, one to s/lib/src/ and one to fix a typo that an
earlier patch somehow introduced (s/PACKAG/PACKAGE/). Sorry about the
latter.

-- 
http://rrt.sc3d.org


0001-Set-cut_dir-properly-and-add-mode-line-for-Emacs.patch
Description: Binary data


0002-Use-src-not-lib-as-root-of-source-in-example-Makefil.patch
Description: Binary data

Re: Mentions of GSS in gnulib.texi

[Reuben Thomas]

On 21 September 2010 13:34, Simon Josefsson  wrote:
> Reuben Thomas  writes:
>
>> Are the mentions of GSS in the section "Out of memory handling" bogus
>> cut-and-paste-o's or similar? A bit of googling suggests that the text
>> has indeed been cut and pasted from the GNU GSS manual. It seems that
>> this section is essentially meant to document xalloc_die (not
>> xalloc_fail_func, which is the name this section actually uses).
>>
>> Should the section be deleted? Rewritten?
>
> It is a cut'n'paste typo.  It could be rewritten or improved.

OK. I'm happy to do that, but I'm still not clear what this section is
documenting in gnulib.

-- 
http://rrt.sc3d.org

Re: On OpenBSD and if_freenameindex(3).

[Mats Erik Andersson]

tisdag den 21 september 2010 klockan 14:22 skrev Simon Josefsson detta:
> As an initial response to this problem, I'm installing a self check of
> the net/if.h interface.  See below.  Mats, if you could quote the
> compiler errors you get when building the self-check below on OpenBSD,
> that would be useful.  The next step is to see how gnulib can provide a
> replacement that works on various systems.  Perhaps OpenBSD isn't the
> only system not working here.
> 
> /Simon

Quickest reply without need to test compile:

   #include 
   #include 
   #include 

is the mandatory order for OpenBSD! Lest  knows that,
the test must augmented. Will return later for more info.

Mats E A

Re: On OpenBSD and if_freenameindex(3).

[Simon Josefsson]

Mats Erik Andersson  writes:

> tisdag den 21 september 2010 klockan 14:22 skrev Simon Josefsson detta:
>> As an initial response to this problem, I'm installing a self check of
>> the net/if.h interface.  See below.  Mats, if you could quote the
>> compiler errors you get when building the self-check below on OpenBSD,
>> that would be useful.  The next step is to see how gnulib can provide a
>> replacement that works on various systems.  Perhaps OpenBSD isn't the
>> only system not working here.
>> 
>> /Simon
>
> Quickest reply without need to test compile:
>
>#include 
>#include 
>#include 
>
> is the mandatory order for OpenBSD! Lest  knows that,
> the test must augmented. Will return later for more info.

That's the first thing a gnulib net/if.h replacement header should
provide then, since I believe the net/if.h header needs to be
self-contained according to POSIX.

It would be interesting to see if the self tests works even if you make
the above modification, though.  Also try running it with a command line
parameter and check that it prints all the host interfaces on your
machine.

Thanks,
/Simon

Re: pmccabe2html: more nits; build-aux confusion

[Simon Josefsson]

Reuben Thomas  writes:

> On 21 September 2010 13:38, Simon Josefsson  wrote:
>> Reuben Thomas  writes:
>>
>>> 1. The example Makefile.am code has "lib/" rather than "src/" in the
>>> path to the source code, even though it's clearly the package source
>>> that is to be analysed, not the gnulib library code.
>>
>> This is because it is an example, and the projects I used it for had the
>> "real" code in lib/ (and the gnulib code in gl/ or similar).  Maybe the
>> example could be changed to use src/ as that may be more common, but
>> still, it is an example snippet that needs to be adapted by the
>> maintainer anyway...
>
> Indeed. Maybe src/ is rather commoner as a source directory?
>
> Attached, two patches, one to s/lib/src/ and one to fix a typo that an
> earlier patch somehow introduced (s/PACKAG/PACKAGE/). Sorry about the
> latter.

Thanks, applied.  In the future, please also write a ChangeLog entry.

/Simon

Re: Another minor patch to pmccabe2html

[Simon Josefsson]

Reuben Thomas  writes:

> On 21 September 2010 13:28, Simon Josefsson  wrote:
>> Reuben Thomas  writes:
>>> By the way, is there some reason to keep this file and pmccabe.css in
>>> gnulib rather than push it upstream to pmccabe, and make the gnulib
>>> module just make the test and suggest an appropriate Makefile.am patch
>>> with settings for GNU projects?
>>
>> I don't think there is any particular reason for this.  Is upstream
>> actively maintained?
>
> It is maintained, although not actively (i.e. the author is accepting
> bug fixes &c. but not working on it himself).
>
> I have written to him to ask if he's interested.

Sounds good -- please also forward any patches we have (I don't think
there are many except for your recent stuff though?).

I still think it makes sense to have a copy in gnulib, just as gnulib
contains a copy of many other things pulled in from other sources.  See
config/srclist.txt.  We need to figure out how to pull in the latest
copy though...

/Simon

Re: Mentions of GSS in gnulib.texi

[Simon Josefsson]

Reuben Thomas  writes:

> On 21 September 2010 13:34, Simon Josefsson  wrote:
>> Reuben Thomas  writes:
>>
>>> Are the mentions of GSS in the section "Out of memory handling" bogus
>>> cut-and-paste-o's or similar? A bit of googling suggests that the text
>>> has indeed been cut and pasted from the GNU GSS manual. It seems that
>>> this section is essentially meant to document xalloc_die (not
>>> xalloc_fail_func, which is the name this section actually uses).
>>>
>>> Should the section be deleted? Rewritten?
>>
>> It is a cut'n'paste typo.  It could be rewritten or improved.
>
> OK. I'm happy to do that, but I'm still not clear what this section is
> documenting in gnulib.

The intent was to document how the xalloc-die module is used by many
other modules in gnulib to handle out of memory conditions.  Maybe you
are right and it is no longer useful to have in the manual, as it could
be documented in the xalloc-die node instead  Still, adding this was
a result of my confusion about how it worked a long time ago, and others
may have similar confusion in the future, so maybe there is some value.

/Simon

Re: pmccabe2html: more nits; build-aux confusion

[Reuben Thomas]

On 21 September 2010 14:55, Simon Josefsson  wrote:
> Reuben Thomas  writes:
>
>> On 21 September 2010 13:38, Simon Josefsson  wrote:
>>> Reuben Thomas  writes:
>>>
 1. The example Makefile.am code has "lib/" rather than "src/" in the
 path to the source code, even though it's clearly the package source
 that is to be analysed, not the gnulib library code.
>>>
>>> This is because it is an example, and the projects I used it for had the
>>> "real" code in lib/ (and the gnulib code in gl/ or similar).  Maybe the
>>> example could be changed to use src/ as that may be more common, but
>>> still, it is an example snippet that needs to be adapted by the
>>> maintainer anyway...
>>
>> Indeed. Maybe src/ is rather commoner as a source directory?
>>
>> Attached, two patches, one to s/lib/src/ and one to fix a typo that an
>> earlier patch somehow introduced (s/PACKAG/PACKAGE/). Sorry about the
>> latter.
>
> Thanks, applied.  In the future, please also write a ChangeLog entry.

Yes, sorry, not writing ChangeLog entries for patches is a very bad
habit of mine which I always tell myself off for and it's about time I
actually did something about it.

-- 
http://rrt.sc3d.org

Re: Another minor patch to pmccabe2html

[Reuben Thomas]

On 21 September 2010 14:57, Simon Josefsson  wrote:
>
> Sounds good -- please also forward any patches we have (I don't think
> there are many except for your recent stuff though?).
>
> I still think it makes sense to have a copy in gnulib, just as gnulib
> contains a copy of many other things pulled in from other sources.  See
> config/srclist.txt.  We need to figure out how to pull in the latest
> copy though...

OK; I'll see what his response is.

-- 
http://rrt.sc3d.org

Re: Mentions of GSS in gnulib.texi

[Reuben Thomas]

On 21 September 2010 14:59, Simon Josefsson  wrote:
> The intent was to document how the xalloc-die module is used by many
> other modules in gnulib to handle out of memory conditions.  Maybe you
> are right and it is no longer useful to have in the manual, as it could
> be documented in the xalloc-die node instead  Still, adding this was
> a result of my confusion about how it worked a long time ago, and others
> may have similar confusion in the future, so maybe there is some value.

OK, I attach a patch (with ChangeLog entry!) to rewrite the section to
be about gnulib rather than GSS. You're quite right, it's a
cross-cutting concern that deserves documentation in the manual rather
than just in one module.

-- 
http://rrt.sc3d.org


0003-Manual-improve-out-of-memory-documentation.patch
Description: Binary data

Re: On OpenBSD and if_freenameindex(3).

[Eric Blake]

On 09/21/2010 06:22 AM, Simon Josefsson wrote:

As an initial response to this problem, I'm installing a self check of
the net/if.h interface.  See below.  Mats, if you could quote the
compiler errors you get when building the self-check below on OpenBSD,
that would be useful.  The next step is to see how gnulib can provide a
replacement that works on various systems.  Perhaps OpenBSD isn't the
only system not working here.


+#include 
+#include  /* NULL */
+#include  /* printf */
+
+int
+main (int argc, char *argv[])
+{
+  struct if_nameindex ifn, *ifnp, *p;
+  void (*if_fni) (struct if_nameindex *) = if_freenameindex;

Rather than doing this via a struct in main(), after you have already 
dragged in other headers, it would be nicer to use "signature.h" and do 
signature validation at the top of the file.  Would you like me to 
prepare a patch along those lines?


--
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org

Re: module libposix

[Matt Rice]

On Mon, Sep 20, 2010 at 8:55 AM, Bruce Korb  wrote:

>> of determining whether you are
>> running from within a git repository, and there is no such command
>> as 'git root'.
>
> Sorry.  BitKeeper had it and the method for accomplishing it was
> too complicated, so I added an alias and forgot I'd done so:
> [alias]
>        root = !pwd -P
>
> There is an approved way, but it is really obtuse:
>  $(\cd ./$(git rev-parse --show-cdup) && pwd -P)
> Far from the first thing that comes to mind.

hmm, even this doesn't seem to work when the GIT_DIR environment variable is set

Re: module libposix

[Bruce Korb]

Hi,

On Tue, Sep 21, 2010 at 8:50 AM, Matt Rice  wrote:
>> There is an approved way, but it is really obtuse:
>>  $(\cd ./$(git rev-parse --show-cdup) && pwd -P)
>> Far from the first thing that comes to mind.
>
> hmm, even this doesn't seem to work when the GIT_DIR
> environment variable is set

If you google for "git root" you get that answer and it seems to work
for me in a number of environments.  The GIT folks apparently
have a little work to doI like my alias.

Anyway, I solved my issue with a "cd" first:

>local git_ver=$(\cd $sdir ; ./build-aux/git-version-gen /dev/null | \
>sed -e 's/-dirty/-modified/')

yielding:

> int  const _libposix_version = 20100915;
> char const _libposix_git_version[] = "0.0.4260-ef0cb-modified";

and the reconf works, modulo a warning:

>>mk_config> autoreconf -i
>libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `build-aux'.
>libtoolize: copying file `build-aux/ltmain.sh'
>libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `glm4'.
>libtoolize: copying file `glm4/libtool.m4'
>libtoolize: copying file `glm4/ltoptions.m4'
>libtoolize: copying file `glm4/ltsugar.m4'
>libtoolize: copying file `glm4/ltversion.m4'
>libtoolize: copying file `glm4/lt~obsolete.m4'
>libtoolize: `AC_PROG_RANLIB' is rendered obsolete by `LT_INIT'

which needs some fix some place.  The final build fails tho:

>/bin/sh ../libtool --tag=CC --mode=link gcc  -g -O2   -o libposix.la -rpath 
>/usr/local/lib  *.lo asnprintf.o \
> basename-lgpl.o chdir-long.o cloexec.o dirname-lgpl.o dprintf.o dup-safer.o 
> duplocale.o fcntl.o\
>  fd-safer.o fflush.o filenamecat-lgpl.o fprintf.o fpurge.o fseek.o fseeko.o 
> futimens.o getcwd.o gettime.o \
> glob.o ioctl.o isfinite.o isnand.o isnanf.o isnanl.o linkat.o nanosleep.o 
> openat-proc.o pipe-safer.o \
> printf.o printf-args.o printf-parse.o remove.o safe-read.o safe-write.o 
> save-cwd.o snprintf.o sprintf.o \
> stripslash.o strstr.o strtod.o tempname.o utimens.o utimensat.o vasnprintf.o 
> vdprintf.o vfprintf.o \
> vprintf.o vsnprintf.o vsprintf.o xgetcwd.o xmalloc.o
>
>*** Warning: Linking the shared library libposix.la against the non-libtool
>*** objects  asnprintf.o [...] -Wl,-soname -Wl,libposix.so.0 -o 
>.libs/libposix.so.0.0.0
>/usr/bin/ld: asnprintf.o: relocation R_X86_64_32 against `a local symbol' can 
>not be used when \
> making a shared object; recompile with -fPIC
>asnprintf.o: could not read symbols: Bad value
>collect2: ld returned 1 exit status
>make[4]: *** [libposix.la] Error 1
>make[4]: Leaving directory 
>`/usr/local/src/gnulib/gnulib/libposix/libposix/libposix

Looks like more sed work is needed, despite:
>  gnulib-tool --libtool --lib=libposix --create-testdir --source-base=lib 
> --dir=libposix $mods


mk-libposix.sh
Description: Bourne shell script

Re: module libposix

[Matt Rice]

On Tue, Sep 21, 2010 at 9:17 AM, Bruce Korb  wrote:
> Hi,
>
> On Tue, Sep 21, 2010 at 8:50 AM, Matt Rice  wrote:
>>> There is an approved way, but it is really obtuse:
>>>  $(\cd ./$(git rev-parse --show-cdup) && pwd -P)
>>> Far from the first thing that comes to mind.
>>
>> hmm, even this doesn't seem to work when the GIT_DIR
>> environment variable is set
>
> If you google for "git root" you get that answer and it seems to work
> for me in a number of environments.  The GIT folks apparently
> have a little work to doI like my alias.

yeah, I found you'd also need to set GIT_WORK_TREE in addition to
GIT_DIR in this case aka my problem.

Re: On OpenBSD and if_freenameindex(3).

[Mats Erik Andersson]

tisdag den 21 september 2010 klockan 15:52 skrev Simon Josefsson detta:
> Mats Erik Andersson  writes:
> 
> > tisdag den 21 september 2010 klockan 14:22 skrev Simon Josefsson detta:
> >> As an initial response to this problem, I'm installing a self check of
> >> the net/if.h interface.  See below.  Mats, if you could quote the
> >> compiler errors you get when building the self-check below on OpenBSD,
> >> that would be useful.  The next step is to see how gnulib can provide a
> >> replacement that works on various systems.  Perhaps OpenBSD isn't the
> >> only system not working here.
> >> 
> >> /Simon
> >
> > Quickest reply without need to test compile:
> >
> >#include 
> >#include 
> >#include 
> >
> > is the mandatory order for OpenBSD! Lest  knows that,
> > the test must augmented. Will return later for more info.
> 
> That's the first thing a gnulib net/if.h replacement header should
> provide then, since I believe the net/if.h header needs to be
> self-contained according to POSIX.
> 
> It would be interesting to see if the self tests works even if you make
> the above modification, though.  Also try running it with a command line
> parameter and check that it prints all the host interfaces on your
> machine.

My protocol "report_for_test_net_if.txt" is attached. I am not able
to compile the test into any working executable for OpenBSD 4.6.
The mishaps are due to "if_freenameindex".

In contrast, the original text works for Debian Squeeze, of course.

Mats E A
Test protocol of "test-net_if.c" on OpenBSD 4.6
===

Common compiling step

  $ gcc test-net_if.c

Line numbering in printouts is consistent since all of
my inclusion additions were inserted once and then
deactivated using "//" as protector.

##
## Only  removed from the suggested module.
##

In file included from test-net_if.c:22:
/usr/include/net/if.h:240: error: `AF_MAX' undeclared here (not in a function)
/usr/include/net/if.h:578: error: field `ifru_addr' has incomplete type
/usr/include/net/if.h:579: error: field `ifru_dstaddr' has incomplete type
/usr/include/net/if.h:580: error: field `ifru_broadaddr' has incomplete type
/usr/include/net/if.h:598: error: field `ifra_addr' has incomplete type
/usr/include/net/if.h:599: error: field `ifra_dstaddr' has incomplete type
/usr/include/net/if.h:601: error: field `ifra_mask' has incomplete type
/usr/include/net/if.h:639: error: field `addr' has incomplete type
/usr/include/net/if.h:640: error: field `dstaddr' has incomplete type
In file included from /usr/include/net/if.h:657,
 from test-net_if.c:22:
/usr/include/net/if_arp.h:79: error: field `arp_pa' has incomplete type
/usr/include/net/if_arp.h:80: error: field `arp_ha' has incomplete type
test-net_if.c: In function `main':
test-net_if.c:30: error: `if_freenameindex' undeclared (first use in this 
function)
test-net_if.c:30: error: (Each undeclared identifier is reported only once
test-net_if.c:30: error: for each function it appears in.)

##
## Addition:
##
## #include 
##

In file included from test-net_if.c:22:
/usr/include/net/if.h:240: error: `AF_MAX' undeclared here (not in a function)
/usr/include/net/if.h:578: error: field `ifru_addr' has incomplete type
/usr/include/net/if.h:579: error: field `ifru_dstaddr' has incomplete type
/usr/include/net/if.h:580: error: field `ifru_broadaddr' has incomplete type
/usr/include/net/if.h:598: error: field `ifra_addr' has incomplete type
/usr/include/net/if.h:599: error: field `ifra_dstaddr' has incomplete type
/usr/include/net/if.h:601: error: field `ifra_mask' has incomplete type
/usr/include/net/if.h:639: error: field `addr' has incomplete type
/usr/include/net/if.h:640: error: field `dstaddr' has incomplete type
In file included from /usr/include/net/if.h:657,
 from test-net_if.c:22:
/usr/include/net/if_arp.h:79: error: field `arp_pa' has incomplete type
/usr/include/net/if_arp.h:80: error: field `arp_ha' has incomplete type
test-net_if.c: In function `main':
test-net_if.c:30: error: `if_freenameindex' undeclared (first use in this 
function)
test-net_if.c:30: error: (Each undeclared identifier is reported only once
test-net_if.c:30: error: for each function it appears in.)

##
## Addition:
##
## #include 
##

In file included from test-net_if.c:21:
/usr/include/sys/socket.h:152: error: syntax error before "u_int8_t"
/usr/include/sys/socket.h:170: error: syntax error before "u_int8_t"
/usr/include/sys/socket.h:173: error: syntax error before "u_int64_t"
/usr/include/sys/socket.h:239: error: syntax error before "uid_t"
/usr/include/sys/socket.h:244: error: syntax error before "gid_t"
/usr/include/sys/socket.h:372: error: syntax error before "socklen_t"
/usr/include/sys/socket.h:376: error: syntax error before "socklen_t"
/usr/include/sys/socket.h:398: error: syntax error before "socklen_t"
/usr/include/sys/socket.h:454: error: syntax error before "caddr_t"
/usr/include/sys/socket.h:458: error: syntax e

Re: On OpenBSD and if_freenameindex(3).

[Bruno Haible]

Mats Erik Andersson wrote:
> In OpenBSD (definitely in 4.6) there is a POSIX violation,
> quoting Simon here, since the header file states
> 
> ### /usr/include/net/if.h
> 
> #define if_freenameindex(x) free(x)
> 
> This macro causes difficulties ...

Indeed, according to POSIX:2008 [1], a macro may be provided by the system, but
the function needs to be provided as well.

Bruno

[1] 
http://www.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_01_01

Re: no pthread_spinlock_t on Mac OS 10.6.4

[Paul Eggert]

On 09/21/10 03:43, Bruno Haible wrote:
> The modules 'lock', 'tls',
> etc. are needed by the modules 'strsignal', 'fstrcmp', and 'localename'.
> Basically, every piece of code that wants to provide multithreaded
> access to a global variable (may it be a registry or cache or anything)
> needs locking.

Yes, but the problem is that coreutils does not need and does not want
that multithreaded access, and yet it has to build the multithreaded
support anyway.  The runtime cost is probably small, but it introduces
dependencies and porting problems that are not worth the hassle.  And
I worry that it may cause unreliability at runtime, on some platforms.

It'd be better if applications could say "I don't need gnulib to be
multithread-safe, and please don't bother with thread-safety"
when it incorporates library code from gnulib.  Even 'sort', the only
coreutils program that is multithreaded, doesn't need the gnulib code
itself to be thread-safe.

>> +   AC_CHECK_TYPES([pthread_t, pthread_spinlock_t])
> 
> It would be wise to include  here. Not all systems define
> these types in ; some (e.g. mingw pthreads-win32) require
> a #include . This include is not part of AC_INCLUDES_DEFAULT.

Thanks, I'll incorporate the following further patch in my next suggestion.
I don't think this'll affect Gary's problem.

--- old/m4/pthread.m4   2010-09-21 00:25:57.628643000 -0700
+++ new/m4/pthread.m4   2010-09-21 10:03:50.638754000 -0700
@@ -15,7 +15,11 @@ AC_DEFUN([gl_PTHREAD_CHECK],
  HAVE_PTHREAD_H=0
fi
 
-   AC_CHECK_TYPES([pthread_t, pthread_spinlock_t])
+   AC_CHECK_TYPES([pthread_t, pthread_spinlock_t], [], [],
+ [AC_INCLUDES_DEFAULT[
+  #if HAVE_PTHREAD_H
+   #include 
+  #endif]])
if test $ac_cv_type_pthread_t != yes; then
  HAVE_PTHREAD_T=0
fi

Re: no pthread_spinlock_t on Mac OS 10.6.4

[Bruno Haible]

Paul Eggert wrote:
> the problem is that coreutils does not need and does not want
> that multithreaded access, and yet it has to build the multithreaded
> support anyway.  ...
> It'd be better if applications could say "I don't need gnulib to be
> multithread-safe, and please don't bother with thread-safety"

You can do so by inserting
  gl_use_threads_default=no
in your configure.ac, before the invocations of gl_INIT_EARLY and gl_INIT.

Users who install coreutils can do so by passing the option --disable-threads.

But beware: since some coreutils programs _are_ multithreaded (namely,
'sort'), this option can introduce bugs, if you don't control very carefully
which API you invoke while the concurrent threads are running.

Bruno

Re: no pthread_spinlock_t on Mac OS 10.6.4

[Paul Eggert]

On 09/21/10 10:40, Bruno Haible wrote:
> You can do so by inserting
>   gl_use_threads_default=no
> in your configure.ac, before the invocations of gl_INIT_EARLY and gl_INIT.

Thanks, I didn't know that.  I tried it, and found one minor glitch.
"configure" said "checking for multithread API to use... no"
which might imply to the casual reader that the resulting coreutils
would not use multiple threads anywhere.  How about appending
"within threadlib" to that message?

Also, it'd be helpful to document gl_use_threads_default.

Perhaps the following patch?


diff --git a/m4/threadlib.m4 b/m4/threadlib.m4
index bff01bc..b6c1817 100644
--- a/m4/threadlib.m4
+++ b/m4/threadlib.m4
@@ -282,7 +282,7 @@ int main ()
   fi
 fi
   fi
-  AC_MSG_CHECKING([for multithread API to use])
+  AC_MSG_CHECKING([for multithread API to use within threadlib])
   AC_MSG_RESULT([$gl_threads_api])
   AC_SUBST([LIBTHREAD])
   AC_SUBST([LTLIBTHREAD])
diff --git a/modules/gettext b/modules/gettext
index cab538e..787f237 100644
--- a/modules/gettext
+++ b/modules/gettext
@@ -38,6 +38,13 @@ gettext-h
 havelib
 
 configure.ac:
+# If your applications do not need gnulib to be multithread-safe,
+# either because they don't use threads or because they carefully
+# control which APIs are invoked while concurrent threads are running,
+# then you can avoid some build-time hassles and run-time overhead by
+# inserting:
+# gl_use_threads_default=no
+# early in configure.ac, before the invocations of gl_INIT_EARLY and gl_INIT.
 AM_GNU_GETTEXT([external])
 AM_GNU_GETTEXT_VERSION([0.18.1])
 
diff --git a/modules/threadlib b/modules/threadlib
index 9e3438c..3e2226a 100644
--- a/modules/threadlib
+++ b/modules/threadlib
@@ -13,6 +13,13 @@ configure.ac-early:
 gl_THREADLIB_EARLY
 
 configure.ac:
+# If your applications do not need gnulib to be multithread-safe,
+# either because they don't use threads or because they carefully
+# control which APIs are invoked while concurrent threads are running,
+# then you can avoid some build-time hassles and run-time overhead by
+# inserting:
+# gl_use_threads_default=no
+# early in configure.ac, before the invocations of gl_INIT_EARLY and gl_INIT.
 gl_THREADLIB
 
 Makefile.am:

Re: no pthread_spinlock_t on Mac OS 10.6.4

[Paul Eggert]

Gary, could you please also try the following patch to coreutils,
either by itself, or along with the updated gnulib patch?  Thanks.

configure: default gnulib to not using threads

* configure.ac: Set gl_use_threads_default=no so that gnulib is
configured without threading.  The only coreutils application that
uses threads (namely 'sort') does not invoke gnulib code in ways
that could lead to races.  Setting this flag simplifies
configuration, making it less likely for builds to fail, and
perhaps preventing some runtime gotchas.
diff --git a/configure.ac b/configure.ac
index acd397e..15368f2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -35,6 +35,11 @@ AC_CONFIG_HEADERS([lib/config.h:lib/config.hin])
 AM_INIT_AUTOMAKE([1.11.1 dist-xz color-tests parallel-tests])
 AM_SILENT_RULES([yes]) # make --enable-silent-rules the default.

+# The gnulib code need not be multithread-safe.  Only 'sort' is
+# multithreaded, and its concurrent threads do not require gnulib's
+# multithread-aware code.
+gl_use_threads_default=no
+
 AC_PROG_CC_STDC
 AM_PROG_CC_C_O
 AC_PROG_CPP

Re: On OpenBSD and if_freenameindex(3).

[Simon Josefsson]

Eric Blake  writes:

> On 09/21/2010 06:22 AM, Simon Josefsson wrote:
>> As an initial response to this problem, I'm installing a self check of
>> the net/if.h interface.  See below.  Mats, if you could quote the
>> compiler errors you get when building the self-check below on OpenBSD,
>> that would be useful.  The next step is to see how gnulib can provide a
>> replacement that works on various systems.  Perhaps OpenBSD isn't the
>> only system not working here.
>
> +#include 
> +#include  /* NULL */
> +#include  /* printf */
> +
> +int
> +main (int argc, char *argv[])
> +{
> +  struct if_nameindex ifn, *ifnp, *p;
> +  void (*if_fni) (struct if_nameindex *) = if_freenameindex;
>
> Rather than doing this via a struct in main(), after you have already
> dragged in other headers, it would be nicer to use "signature.h" and
> do signature validation at the top of the file.  Would you like me to
> prepare a patch along those lines?

Yes please do and push it.  I haven't used the signature.h mechanism (or
I have forgotten how to), so I'll learn if you post the patch.

/Simon

Re: On OpenBSD and if_freenameindex(3).

[Simon Josefsson]

Mats Erik Andersson  writes:

> My protocol "report_for_test_net_if.txt" is attached. I am not able
> to compile the test into any working executable for OpenBSD 4.6.
> The mishaps are due to "if_freenameindex".

Thanks, this is very useful.

Is there a if_freenameindex symbol in the OpenBSD libc?  Use 'nm' on
/lib/libc.so to test.  If there is, it might be an InetUtils bug after
all, since POSIX allows if_freenameindex to ALSO be defined as a CPP
macro.

/Simon

Re: On OpenBSD and if_freenameindex(3).

[Simon Josefsson]

Bruno Haible  writes:

> Mats Erik Andersson wrote:
>> In OpenBSD (definitely in 4.6) there is a POSIX violation,
>> quoting Simon here, since the header file states
>> 
>> ### /usr/include/net/if.h
>> 
>> #define if_freenameindex(x) free(x)
>> 
>> This macro causes difficulties ...
>
> Indeed, according to POSIX:2008 [1], a macro may be provided by the system, 
> but
> the function needs to be provided as well.
>
> Bruno
>
> [1] 
> http://www.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_01_01

I guess this means the signature testing code should actually test that
(if_freenameindex), and not if_freenameindex, matches the prototype,
right?  This to make sure that the function prototype (if existing) is
used instead of the CPP macro.  Perhaps signature.h already does this
though...

/Simon

Re: Mentions of GSS in gnulib.texi

[Simon Josefsson]

Reuben Thomas  writes:

> On 21 September 2010 14:59, Simon Josefsson  wrote:
>> The intent was to document how the xalloc-die module is used by many
>> other modules in gnulib to handle out of memory conditions.  Maybe you
>> are right and it is no longer useful to have in the manual, as it could
>> be documented in the xalloc-die node instead  Still, adding this was
>> a result of my confusion about how it worked a long time ago, and others
>> may have similar confusion in the future, so maybe there is some value.
>
> OK, I attach a patch (with ChangeLog entry!) to rewrite the section to
> be about gnulib rather than GSS. You're quite right, it's a
> cross-cutting concern that deserves documentation in the manual rather
> than just in one module.

Thanks, applied.  I didn't see a patch for ChangeLog in there though?  I
added it myself and pushed it separately.

/Simon

Re: On OpenBSD and if_freenameindex(3).

[Eric Blake]

On 09/21/2010 02:41 PM, Simon Josefsson wrote:

Eric Blake  writes:


On 09/21/2010 06:22 AM, Simon Josefsson wrote:

As an initial response to this problem, I'm installing a self check of
the net/if.h interface.  See below.  Mats, if you could quote the
compiler errors you get when building the self-check below on OpenBSD,
that would be useful.  The next step is to see how gnulib can provide a
replacement that works on various systems.  Perhaps OpenBSD isn't the
only system not working here.


+#include
+#include  /* NULL */
+#include  /* printf */
+
+int
+main (int argc, char *argv[])
+{
+  struct if_nameindex ifn, *ifnp, *p;
+  void (*if_fni) (struct if_nameindex *) = if_freenameindex;

Rather than doing this via a struct in main(), after you have already
dragged in other headers, it would be nicer to use "signature.h" and
do signature validation at the top of the file.  Would you like me to
prepare a patch along those lines?


Yes please do and push it.  I haven't used the signature.h mechanism (or
I have forgotten how to), so I'll learn if you post the patch.


It turns out that MirBSD has the same bug regarding if_freenameindex not 
being a function.  So I've gone ahead and documented that; we can update 
the documentation when we implement the net_if (replacement header) and 
if_freenameindex (function implementation) modules.


Also, if the test fails, it should print to stderr, not stdout.

Meanwhile, we have generally been writing the tests so that the header 
test only checks things guaranteed by the header replacement with no 
other function modules in use, such as macros like IF_NAMESIZE and types 
like struct if_nameindex; while leaving signature checks up to the 
modules that actually replace functions.  But until we have any function 
modules, then the header test is the right place to test signatures. 
So, when we actually implement an if_freenameindex module, we'll 
probably rearrange part of this test into a new test file.  But I've run 
out of time for implementing net_if and if_freenameindex today, so 
here's what I'm pushing now:



diff --git i/ChangeLog w/ChangeLog
index 088122e..9434ba5 100644
--- i/ChangeLog
+++ w/ChangeLog
@@ -1,3 +1,11 @@
+2010-09-21  Eric Blake  
+
+   net_if: enhance tests
+   * tests/test-net_if.c (main): Move signature checks earlier.
+   Print failures to stderr.
+   * doc/posix-functions/if_freenameindex.texi (if_freenameindex):
+   Document the bug that we do not yet fix.
+
 2010-09-21  Reuben Thomas  

* doc/gnulib.texi (Out of memory handling): Rewrite section to be
diff --git i/doc/posix-functions/if_freenameindex.texi 
w/doc/posix-functions/if_freenameindex.texi

index 97cdc9f..1dcf096 100644
--- i/doc/posix-functions/if_freenameindex.texi
+++ w/doc/posix-functions/if_freenameindex.texi
@@ -14,5 +14,11 @@ if_freenameindex
 @itemize
 @item
 This function is missing on some platforms:
-OpenBSD 3.8, HP-UX 11, IRIX 6.5, OSF/1 4.0, Solaris 7, Cygwin 1.5.x, 
mingw, Interix 3.5, BeOS.

+OpenBSD 3.8, HP-UX 11, IRIX 6.5, OSF/1 4.0, Solaris 7, Cygwin 1.5.x,
+mingw, Interix 3.5, BeOS.
+
+...@item
+This is available only as a macro, rather than a function, on some
+platforms:
+OpenBSD 4.6, MirBSD 10.
 @end itemize
diff --git i/modules/net_if-tests w/modules/net_if-tests
index 4349e85..ace657d 100644
--- i/modules/net_if-tests
+++ w/modules/net_if-tests
@@ -1,5 +1,6 @@
 Files:
 tests/test-net_if.c
+tests/signature.h

 Depends-on:

diff --git i/tests/test-net_if.c w/tests/test-net_if.c
index f1cdb99..15926ff 100644
--- i/tests/test-net_if.c
+++ w/tests/test-net_if.c
@@ -17,32 +17,33 @@
 /* Written by Simon Josefsson , 2010.  */

 #include 
+
 #include 
+
+#include "signature.h"
+SIGNATURE_CHECK (if_freenameindex, void, (struct if_nameindex *));
+SIGNATURE_CHECK (if_indextoname, char *, (unsigned int, char *));
+SIGNATURE_CHECK (if_nameindex, struct if_nameindex *, (void));
+SIGNATURE_CHECK (if_nametoindex, unsigned int, (const char *));
+
 #include  /* NULL */
-#include  /* printf */
+#include  /* fprintf */

 int
 main (int argc, char *argv[])
 {
-  struct if_nameindex ifn, *ifnp, *p;
-  void (*if_fni) (struct if_nameindex *) = if_freenameindex;
-  char *(*if_itn)(unsigned, char *) = if_indextoname;
-  struct if_nameindex  *(*if_ni)(void) = if_nameindex;
-  unsigned (*if_nti)(const char *) = if_nametoindex;
-
-  ifn.if_index = 42;
-  ifn.if_name = "foo";
+  struct if_nameindex *ifnp, *p;

   p = ifnp = if_nameindex ();
   if (ifnp == NULL)
 {
-  printf ("if_nameindex returned NULL\n");
+  fputs ("if_nameindex returned NULL\n", stderr);
   return 1;
 }

   while (p->if_index)
 {
-  unsigned idx;
+  unsigned int idx;
   char buf[IF_NAMESIZE];
   char *q;

@@ -52,25 +53,26 @@ main (int argc, char *argv[])
   idx = if_nametoindex (p->if_name);
   if (idx != p->if_index)
 {
-  printf ("if_nametoindex (%s) = %d != %d\n",
-  p->if_name, idx, p->if_index);
+   

Re: module libposix

[Bruce Korb]

>>/bin/sh ../libtool --tag=CC --mode=link gcc  -g -O2   -o libposix.la -rpath 
>>/usr/local/lib  .libs/*.o asnprintf.o \
>> basename-lgpl.o chdir-long.o cloexec.o dirname-lgpl.o dprintf.o dup-safer.o 
>> duplocale.o fcntl.o\
>>  fd-safer.o fflush.o filenamecat-lgpl.o fprintf.o fpurge.o fseek.o fseeko.o 
>> futimens.o getcwd.o gettime.o \
>> glob.o ioctl.o isfinite.o isnand.o isnanf.o isnanl.o linkat.o nanosleep.o 
>> openat-proc.o pipe-safer.o \
>> printf.o printf-args.o printf-parse.o remove.o safe-read.o safe-write.o 
>> save-cwd.o snprintf.o sprintf.o \
>> stripslash.o strstr.o strtod.o tempname.o utimens.o utimensat.o vasnprintf.o 
>> vdprintf.o vfprintf.o \
>> vprintf.o vsnprintf.o vsprintf.o xgetcwd.o xmalloc.o
>>
>>*** Warning: Linking the shared library libposix.la against the non-libtool
>>*** objects  asnprintf.o [...] -Wl,-soname -Wl,libposix.so.0 -o 
>>.libs/libposix.so.0.0.0
>>/usr/bin/ld: asnprintf.o: relocation R_X86_64_32 against `a local symbol' can 
>>not be used when \
>> making a shared object; recompile with -fPIC
>>asnprintf.o: could not read symbols: Bad value
>>collect2: ld returned 1 exit status
>>make[4]: *** [libposix.la] Error 1
>>make[4]: Leaving directory 
>>`/usr/local/src/gnulib/gnulib/libposix/libposix/libposix

I took a peek at this.  The referenced .o objects get generated from
being part of
EXTRA_libposix_la_SOURCES and the members of libposix_la_SOURCES are
compiled correctly.  I'd have expected that these sources would not actually get
compiled at all.  But there is some magic here.

We have:
   EXTRA_SOURCES
   libposix_la_SOURCES
   EXTRA_libposix_la_SOURCES

The names in the first are simply rolled into the distribution tarball.
The second get built into the shared object that is to be installed.
The third get compiled non-PIC and an attempt is made to link
them into the shared object, too.  Libtool doesn't like it.  I don't
either.  Should these be EXTRA_SOURCES or libposix_la_SOURCES?

Re: On OpenBSD and if_freenameindex(3).

[Mats Erik Andersson]

tisdag den 21 september 2010 klockan 22:46 skrev Simon Josefsson detta:
> Mats Erik Andersson  writes:
> 
> > My protocol "report_for_test_net_if.txt" is attached. I am not able
> > to compile the test into any working executable for OpenBSD 4.6.
> > The mishaps are due to "if_freenameindex".
> 
> Thanks, this is very useful.
> 
> Is there a if_freenameindex symbol in the OpenBSD libc?  Use 'nm' on
> /lib/libc.so to test.  If there is, it might be an InetUtils bug after
> all, since POSIX allows if_freenameindex to ALSO be defined as a CPP
> macro.

Negative answer, no symbol "if_freenameindex" present in "libc.so.51.0".

Of course the symbols "if_nameindex", "if_nametoindex", and "if_indextoname"
are present. Therefore not even the relaxed demand that Bruno Haible
mentioned is satisfied. "POSIX hin und POSIX her, wen kümmert's?"


Regards,
Mats E A

Re: Mentions of GSS in gnulib.texi

[Reuben Thomas]

On 21 September 2010 21:51, Simon Josefsson  wrote:
> Thanks, applied.  I didn't see a patch for ChangeLog in there though?  I
> added it myself and pushed it separately.

I used git format-patch, which seemed to put my ChangeLog entry at the
top. I see that that is not specifically a patch to ChangeLog, but I
guess it works better when the ChangeLog is generated rather than
maintained manually; can't it be applied anyway?

-- 
http://rrt.sc3d.org

[PATCH] fix infinite loop in mbmemcasecoll

[Pádraig Brady]

I was testing multi-byte enhancements to coreutils/join with:
LC_ALL=en_US.utf8 join -i <(env printf '1\x00\n') <(env printf '2\x00\n')
and noticed it spun the CPU because of the NUL char.
The attached fixes the issue for me. This function is supposed
to skip over NUL chars like this right?

cheers,
Pádraig.

--- a/lib/mbmemcasecoll.c   2010-01-04 01:10:30.0 +
+++ b/lib/mbmemcasecoll.c   2010-09-21 23:52:23.0 +
@@ -61,6 +63,8 @@
 break;
   if (n1 != (size_t)(-1))
 {
+  if (n1 == 0)
+n1 = 1; /* copy NUL characters.  */
   wint_t wc2 = towlower (wc1);

   if (wc2 != wc1)

Re: no pthread_spinlock_t on Mac OS 10.6.4

[Gary V. Vaughan]

Hi Paul,

On 21 Sep 2010, at 14:49, Paul Eggert wrote:
> Could you try the following patch instead?  It tries an idea discussed
> earlier today, namely, fall back on mutexes if spinlocks aren't there.
> You'll need not only to update lib/pthread.in.h and m4/pthread.m4, but
> also to get that code from modules/pthread into your makefile; I did
> that by manually editing the "begin gnulib module pthread" section of
> lib/gnulib.mk.

I like this idea much better than disabling threads entirely on macosx.

But the patch causes a bizarre and apparently unrelated compilation
error:

  ; make V=1
  gcc -std=gnu99  -I. -I../lib  -g -O2 -MT sigprocmask.o -MD -MP -MF 
.deps/sigprocmask.Tpo -c -o sigprocmask.o ../lib/sigprocmask.c
  ../lib/sigprocmask.c:87: error: expected identifier or '(' before 'const'
  ../lib/sigprocmask.c:87: error: expected ')' before '&' token
  ../lib/sigprocmask.c:87: error: expected ')' before '!=' token
  ../lib/sigprocmask.c:103: error: expected ')' before '*' token
  ../lib/sigprocmask.c:103: error: expected ')' before '=' token
  ../lib/sigprocmask.c:110: error: expected ')' before '*' token
  ../lib/sigprocmask.c:110: error: expected ')' before '|=' token
  ../lib/sigprocmask.c:130: error: expected ')' before '*' token
  ../lib/sigprocmask.c:130: error: expected ')' before '&=' token
  ../lib/sigprocmask.c:151: error: expected ')' before '*' token
  ../lib/sigprocmask.c:151: error: expected ')' before 

Apparently caused by an errant sigprocmask functions sharing names with
system macros, to create this mess:

  ; gcc -std=c99 -E ../lib/sigprocmask.c | sed '/^$/d' | cat -n
  [[...]]
  2376  int
  2377  ((*(const sigset_t *set) & __sigbits(int sig)) != 0)
  2378  {
  2379if (sig >= 0 && sig < 32)
  2380  {
  2381return (*set >> sig) & 1;
  2382  }
  2383else
  2384  return 0;
  2385  }
  2386  int
  2387  (*(sigset_t *set) = 0, 0)
  2388  {
  2389*set = 0;
  2390return 0;
  2391  }
  2392  int
  2393  (*(sigset_t *set) |= __sigbits(int sig), 0)
  2394  {
  2395if (sig >= 0 && sig < 32)
  2396  {
  2397*set |= 1U << sig;
  2398return 0;
  2399  }
  2400else
  2401  {
  2402(*__error()) = 22;
  2403return -1;
  2404  }
  2405  }
  2406  int
  2407  (*(sigset_t *set) &= ~__sigbits(int sig), 0)
  2408  {
  2409if (sig >= 0 && sig < 32)
  2410  {
  2411*set &= ~(1U << sig);
  2412return 0;
  2413  }
  2414else
  2415  {
  2416(*__error()) = 22;
  2417return -1;
  2418  }
  2419  }
  2420  int
  2421  (*(sigset_t *set) = ~(sigset_t)0, 0)
  2422  {
  2423*set = ((2U << (32 - 1)) - 1) & ~ 0;
  2424return 0;
  2425  }

I suppose this is a result of header ordering?  The only things that have
changed since my previous report are that I've applied the patch below,
tweaked the generated gnulib.mk as suggested, and updated the gnulib
submodule to the tip of master so that the patch can apply.

I tried removing the `# include_next ' but the above error
still stands even then.  So maybe this is an entirely new problem with
latest gnulib?

> Sorry, I can't easily test this as I don't use MacOS.

No problem, glad to help. Sorry I couldn't unravel this any further by
myself.

> diff --git a/lib/pthread.in.h b/lib/pthread.in.h
> index 0fdf9c3..f8e358b 100644
> --- a/lib/pthread.in.h
> +++ b/lib/pthread.in.h
> @@ -19,6 +19,17 @@
> /* Written by Paul Eggert and Glen Lenker.  */
> 
> #ifndef _GL_PTHREAD_H_
> +
> +#if __GNUC__ >= 3
> +...@pragma_system_header@
> +#endif
> +
> +/* The include_next requires a split double-inclusion guard.  */
> +#if @HAVE_PTHREAD_H@
> +# @INCLUDE_NEXT@ @NEXT_PTHREAD_H@
> +#endif
> +
> +#ifndef _GL_PTHREAD_H_
> #define _GL_PTHREAD_H_
> 
> #include 
> @@ -27,7 +38,7 @@
> #include 
> #include 
> 
> -#ifndef HAVE_PTHREAD_T
> +#if ! @HAVE_PTHREAD_T@
>  typedef int pthread_t;
>  typedef int pthread_attr_t;
>  typedef int pthread_barrier_t;
> @@ -40,9 +51,9 @@
>  typedef int pthread_once_t;
>  typedef int pthread_rwlock_t;
>  typedef int pthread_rwlockattr_t;
> - typedef int pthread_spinlock_t;
> #endif
> 
> +#ifndef PTHREAD_COND_INITIALIZER
> #define PTHREAD_COND_INITIALIZER { 0 }
> #define PTHREAD_MUTEX_INITIALIZER { 0 }
> #define PTHREAD_ONCE_INIT { 0 }
> @@ -81,6 +92,9 @@
> 
> #define PTHREAD_SCOPE_SYSTEM 0
> #define PTHREAD_SCOPE_PROCESS 1
> +#endif
> +
> +#if ! @HAVE_PTHREAD_T@
> 
> /* Provide substitutes for the thread functions that should work
>adequately on a single-threaded implementation, where
> @@ -147,6 +161,24 @@ pthread_join (pthread_t thread, void **pvalue)
> }
> 
> static inline int
> +pthread_mutexattr_destroy (pthread_mutexattr_t *attr)
> +{
> +  return 0;
> +}
> +
> +static inline int
> +pthread_mutexattr_init (pthread_mutexattr_t *attr)
> +{
> +  return 0;
> +}
> +
> +static inline int
> +pthread_mutexattr_settype (pthread_mutexattr_t *attr, int attr_type)
> +{
> +  return 0;
> +}
> +
> +static inlin

Re: no pthread_spinlock_t on Mac OS 10.6.4

[Paul Eggert]

On 09/21/2010 10:11 PM, Gary V. Vaughan wrote:

> But the patch causes a bizarre and apparently unrelated compilation
> error:
> 
>   ; make V=1
>   gcc -std=gnu99  -I. -I../lib  -g -O2 -MT sigprocmask.o -MD -MP -MF 
> .deps/sigprocmask.Tpo -c -o sigprocmask.o ../lib/sigprocmask.c
>   ../lib/sigprocmask.c:87: error: expected identifier or '(' before 'const'

I don't see how the patch could do that, unless sigprocmask.c
includes pthread.h somehow.  Can you verify whether that happens,
by using gcc -E?  If so, which file is the immediate includer
of pthread.h?  And if not, what's the difference beween
the output of gcc -E sigprocmask.c, with and without the patch?

Also, could you please try the simpler patch here instead?

http://lists.gnu.org/archive/html/bug-coreutils/2010-09/msg00080.html