Re: [coreutils] Re: Builds of coreutils-8.6.19-1369f

[Ralf Wildenhues]

* Jim Meyering wrote on Sat, Nov 06, 2010 at 06:14:05PM CET:
> Ralf Wildenhues wrote:
> > - Posix does not require IFS to be set upon script startup.  It only 
> > requires
> > that, if IFS is unset, word splitting ought to behave as if it were set to
> > space, tab, and newline, in that order.  That is why the startup code of all
> > autotools scripts explicitly sets IFS, so that saving and restoring works.
> 
> Thanks.  That's good to know, but it appears not to be an issue
> for any shell that gets past the init.sh tests.

Are you sure?  It affects any test that saves and restores IFS in any
way.

Cheers,
Ralf

Re: [coreutils] Re: Builds of coreutils-8.6.19-1369f

[Jim Meyering]

Ralf Wildenhues wrote:

> * Jim Meyering wrote on Sat, Nov 06, 2010 at 06:14:05PM CET:
>> Ralf Wildenhues wrote:
>> > - Posix does not require IFS to be set upon script startup.  It only 
>> > requires
>> > that, if IFS is unset, word splitting ought to behave as if it were set to
>> > space, tab, and newline, in that order.  That is why the startup code of 
>> > all
>> > autotools scripts explicitly sets IFS, so that saving and restoring works.
>>
>> Thanks.  That's good to know, but it appears not to be an issue
>> for any shell that gets past the init.sh tests.
>
> Are you sure?  It affects any test that saves and restores IFS in any
> way.

No, but it looks that way.
When the new FreeBSD 8.1 /bin/sh "local" issue makes it so IFS is
not restored, coreutils gets numerous failures.

I've never seen that before.
It looks like both of the other IFS-restoring coreutils tests would
fail if IFS restoration failed.

$ git grep -w IFS|grep -E 'old|save'
old/fileutils/ChangeLog:* tests/mkdir/perm: Don't put a newline\
   in IFS;  that's not portable to
tests/chmod/usage:old_IFS=$IFS
tests/chmod/usage:  IFS=$old_IFS
tests/init.cfg:  local saved_IFS="$IFS"
tests/init.cfg:  IFS=$saved_IFS
tests/mkdir/perm:  old_IFS=$IFS
tests/mkdir/perm:  IFS=$old_IFS

Do you know of a modern shell that acts as you describe?
I've run the following on a decent selection of systems,
and saw no failure:

for sh in sh bash ksh pdksh dash zsh; do
  type $sh > /dev/null || continue;
  $sh -c 'i=$IFS; test -n "$IFS"' || echo fail
done

If some shell does fail, perhaps init.sh should use a patch like the following.
I hesitate to add code like this, unless there's at least one
known system where it makes a difference.

diff --git a/tests/init.sh b/tests/init.sh
index a57de77..a37d129 100644
--- a/tests/init.sh
+++ b/tests/init.sh
@@ -330,6 +330,12 @@ setup_()
 || fail_ "failed to create temporary directory in $initial_cwd_"
   cd "$test_dir_"

+  # As autoconf-generated configure scripts do, ensure that IFS is defined
+  # initially, so that saving and restoring $IFS works.
+  gl_init_sh_nl_='
+'
+  IFS=" "" $gl_init_sh_nl_"
+
   # This trap statement, along with a trap on 0 below, ensure that the
   # temporary directory, $test_dir_, is removed upon exit as well as
   # upon receipt of any of the listed signals.

MD5 module license

[Sylvain Beucler]

Hi,

The license of the MD5 module is documented as LGPLv2+, but the source
headers say it's under the GPLv2+, and that it's part of the (LGPL)
libc.

What is the actual license? :)

-- 
Sylvain

libposix

[Sylvain Beucler]

Hi,

I saw the new 'libposix' branch and I was curious about it - how is it
supposed to be used?

Also, is there any relationship with
http://libposix.sourceforge.net/ ?

Cheers!

-- 
Sylvain

Re: [coreutils] Re: Builds of coreutils-8.6.19-1369f

[Ralf Wildenhues]

* Jim Meyering wrote on Sun, Nov 07, 2010 at 12:22:13PM CET:
> Ralf Wildenhues wrote:
> > * Jim Meyering wrote on Sat, Nov 06, 2010 at 06:14:05PM CET:
> >> Ralf Wildenhues wrote:
> >> > - Posix does not require IFS to be set upon script startup.  It only 
> >> > requires
> >> > that, if IFS is unset, word splitting ought to behave as if it were set 
> >> > to
> >> > space, tab, and newline, in that order.  That is why the startup code of 
> >> > all
> >> > autotools scripts explicitly sets IFS, so that saving and restoring 
> >> > works.
> >>
> >> Thanks.  That's good to know, but it appears not to be an issue
> >> for any shell that gets past the init.sh tests.
> >
> > Are you sure?  It affects any test that saves and restores IFS in any
> > way.

> Do you know of a modern shell that acts as you describe?
> I've run the following on a decent selection of systems,
> and saw no failure:

Some version of dash did that, IIRC.  A wild guess would
be RH 6 (yes, quite a while ago, I haven't come across it
again since).  Point is that Posix allows the behavior.

> If some shell does fail, perhaps init.sh should use a patch like the 
> following.
> I hesitate to add code like this, unless there's at least one
> known system where it makes a difference.

The fix looks good to me.

Thanks,
Ralf

> --- a/tests/init.sh
> +++ b/tests/init.sh
> @@ -330,6 +330,12 @@ setup_()
>  || fail_ "failed to create temporary directory in $initial_cwd_"
>cd "$test_dir_"
> 
> +  # As autoconf-generated configure scripts do, ensure that IFS is defined
> +  # initially, so that saving and restoring $IFS works.
> +  gl_init_sh_nl_='
> +'
> +  IFS=" ""   $gl_init_sh_nl_"
> +
># This trap statement, along with a trap on 0 below, ensure that the
># temporary directory, $test_dir_, is removed upon exit as well as
># upon receipt of any of the listed signals.
> 

Re: MD5 module license

[Simon Josefsson]

Sylvain Beucler  writes:

> Hi,
>
> The license of the MD5 module is documented as LGPLv2+, but the source
> headers say it's under the GPLv2+, and that it's part of the (LGPL)
> libc.
>
> What is the actual license? :)

The gnulib modules file is the canonical place, which says LGPLv2+.  For
historical reasons the header file says GPLv2+.

/Simon

Re: libposix

[Gary V. Vaughan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Salut Sylvain,

Sylvain Beucler wrote:
> I saw the new 'libposix' branch and I was curious about it - how is it
> supposed to be used?

The idea is to build a standalone library of posix compatible functions
from gnulib that will make writing and porting programs that use the
POSIX APIs easier; and without worrying so much about the (often spotty
and imperfect) POSIX compatibility of the native libraries - ideally
reducing the size and complexity of the configuration of projects that
stick to documented POSIX apis considerably, and in any case saving
drastically on the requirement to copy a large number of gnulib modules
into many separate projects as would otherwise be necessary (as is the
case right now in fact).

Building it should be a matter of:

  $ git clone git://git.savannah.gnu.org/gnulib.git
  $ cd gnulib
  $ git checkout topic/libposix
  $ cd libposix
  $ ./bootstrap
  $ ./configure
  $ make
  $ sudo make install

There are still some pending issues and feedback to be incorporated
before it can be merged back into master.

> Also, is there any relationship with
> http://libposix.sourceforge.net/ ?

I was not aware of that project, so no... no relation :)

Cheers,
- -- 
Gary V. Vaughan (g...@gnu.org)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (Darwin)

iEYEARECAAYFAkzWymcACgkQFRMICSmD1gbc5ACfWMPiLEZcANU17niz+k1qNCuH
y84An0qX7LIQxOiDOVNDjJtRY6tdud/B
=wlDb
-END PGP SIGNATURE-

Re: libposix

[Bruce Korb]

On 11/07/10 04:18, Sylvain Beucler wrote:
> Hi,
> 
> I saw the new 'libposix' branch and I was curious about it - how is it
> supposed to be used?

Once functional, it generates an installable project.
Client projects can test for the existence of libposix and quit if
not present or not recent enough.  The "configure" step becomes very
short.  The configure step for the libposix project will be very,
very, very long indeed.

> Also, is there any relationship with
> http://libposix.sourceforge.net/ ?

That is an attempt to make a portable library that is not a backfill
project, but a replacement project.  gnulib is a backfill project,
with a bunch of "extras" tossed in.  The Source Forge project is also:

* a direct competitor to glibc
* has shown little activity since a year ago

It may keep going, but it has a very long way to go and will likely
never be as portable as gnulib.

Regards, Bruce

Re: [PATCH] [html] Fix copy/paste bug: Use unique name for compiler warnings.

[Bruno Haible]

Thien-Thi Nguyen wrote:
> * MODULES.html.sh: For compiler warnings, use name
> `ansic_ext_compwarn' since `ansic_ext_misc' is already taken.

Thanks. I've applied your patch. (With "git am -3", it applied cleanly.)

Bruno

vasnprintf: support glibc 'I' flag

[Bruno Haible]

Hi,

Just noticed that gnulib's vasnprintf function does not support the same flags
as the underlying system. In particular, glibc's 'I' flag (that causes
localized digits to appear in the output instead of ASCII digits - a feature
used in Farsi and Indic languages) ought to be supported by vasnprintf.

This fixes it.


2010-11-07  Bruno Haible  

vasnprintf: Support I flag on glibc systems.
* lib/printf-parse.h (FLAG_LOCALIZED): New macro.
* lib/printf-parse.c (PRINTF_PARSE): Handle the 'I' flag.
* lib/vasnprintf.c (VASNPRINTF): Pass the 'I' flag on to the system's
snprintf function.
* tests/test-vasnprintf-posix.c (test_function): Test the 'I' flag on
glibc systems.
* tests/test-vasnprintf-posix3.c: New file.
* modules/vasnprintf-posix-tests (Files): Add it.
(TESTS, check_PROGRAMS): Add test-vasnprintf-posix3.

--- lib/printf-parse.c.orig Sun Nov  7 18:50:15 2010
+++ lib/printf-parse.c  Sun Nov  7 17:39:27 2010
@@ -206,6 +206,13 @@
   dp->flags |= FLAG_ZERO;
   cp++;
 }
+#if __GLIBC__ >= 2
+  else if (*cp == 'I')
+{
+  dp->flags |= FLAG_LOCALIZED;
+  cp++;
+}
+#endif
   else
 break;
 }
--- lib/printf-parse.h.orig Sun Nov  7 18:50:15 2010
+++ lib/printf-parse.h  Sun Nov  7 18:48:45 2010
@@ -33,6 +33,9 @@
 #define FLAG_SPACE   8  /* space flag */
 #define FLAG_ALT16  /* # flag */
 #define FLAG_ZERO   32
+#if __GLIBC__ >= 2
+# define FLAG_LOCALIZED 64  /* I flag, uses localized digits */
+#endif
 
 /* arg_index value indicating that no argument is consumed.  */
 #define ARG_NONE(~(size_t)0)
--- lib/vasnprintf.c.orig   Sun Nov  7 18:50:15 2010
+++ lib/vasnprintf.cSun Nov  7 17:45:20 2010
@@ -4754,6 +4754,10 @@
   *fbp++ = ' ';
 if (flags & FLAG_ALT)
   *fbp++ = '#';
+#if __GLIBC__ >= 2
+if (flags & FLAG_LOCALIZED)
+  *fbp++ = 'I';
+#endif
 if (!pad_ourselves)
   {
 if (flags & FLAG_ZERO)
--- modules/vasnprintf-posix-tests.orig Sun Nov  7 18:50:15 2010
+++ modules/vasnprintf-posix-tests  Sun Nov  7 18:13:12 2010
@@ -2,6 +2,7 @@
 tests/test-vasnprintf-posix.c
 tests/test-vasnprintf-posix2.sh
 tests/test-vasnprintf-posix2.c
+tests/test-vasnprintf-posix3.c
 tests/minus-zero.h
 tests/nan.h
 tests/macros.h
@@ -17,6 +18,6 @@
 gt_LOCALE_FR_UTF8
 
 Makefile.am:
-TESTS += test-vasnprintf-posix test-vasnprintf-posix2.sh
+TESTS += test-vasnprintf-posix test-vasnprintf-posix2.sh test-vasnprintf-posix3
 TESTS_ENVIRONMENT += LOCALE_FR='@LOCALE_FR@' LOCALE_FR_UTF8='@LOCALE_FR_UTF8@'
-check_PROGRAMS += test-vasnprintf-posix test-vasnprintf-posix2
+check_PROGRAMS += test-vasnprintf-posix test-vasnprintf-posix2 
test-vasnprintf-posix3
--- tests/test-vasnprintf-posix.c.orig  Sun Nov  7 18:50:15 2010
+++ tests/test-vasnprintf-posix.c   Sun Nov  7 18:47:52 2010
@@ -3658,6 +3658,19 @@
   free (result);
   }
 #endif
+
+#if __GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 2)
+  /* Test that the 'I' flag is supported.  */
+  {
+size_t length;
+char *result =
+  my_asnprintf (NULL, &length, "%Id %d", 1234567, 99);
+ASSERT (result != NULL);
+ASSERT (strcmp (result, "1234567 99") == 0);
+ASSERT (length == strlen (result));
+free (result);
+  }
+#endif
 }
 
 static char *
=== tests/test-vasnprintf-posix3.c ===
/* Test of POSIX compatible vasnprintf() and asnprintf() 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 Bruno Haible , 2010.  */

#include 

#include "vasnprintf.h"

#include 
#include 
#include 

#include "macros.h"

static void
test_function (char * (*my_asnprintf) (char *, size_t *, const char *, ...))
{
  /* glibc >= 2.2 supports the 'I' flag, and in glibc >= 2.2.3 the fa_IR
 locale defines the 'outdigits' to be U+06F0..U+06F9.
 So we test for glibc >= 2.3.  */
#if __GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 3)
  /* Test that the 'I' flag is supported.  */
  {
size_t length;
char *result =
  my_asnprintf (NULL, &length, "%Id %d

Re: libposix

[Sylvain Beucler]

Hi Gary,

On Sun, Nov 07, 2010 at 10:48:55PM +0700, Gary V. Vaughan wrote:
> Sylvain Beucler wrote:
> > I saw the new 'libposix' branch and I was curious about it - how is it
> > supposed to be used?
> 
> The idea is to build a standalone library of posix compatible functions
> from gnulib that will make writing and porting programs that use the
> POSIX APIs easier; and without worrying so much about the (often spotty
> and imperfect) POSIX compatibility of the native libraries - ideally
> reducing the size and complexity of the configuration of projects that
> stick to documented POSIX apis considerably, and in any case saving
> drastically on the requirement to copy a large number of gnulib modules
> into many separate projects as would otherwise be necessary (as is the
> case right now in fact).
> 
> Building it should be a matter of:
> 
>   $ git clone git://git.savannah.gnu.org/gnulib.git
>   $ cd gnulib
>   $ git checkout topic/libposix
>   $ cd libposix
>   $ ./bootstrap
>   $ ./configure
>   $ make
>   $ sudo make install
> 
> There are still some pending issues and feedback to be incorporated
> before it can be merged back into master.

That sounds good, and this also sounds like quite a change from the
current gnulib.

As far as I understand, gnulib performs tests at ./configure time to
decide whether to use the gnulib replacement, or rely on the
decent-enough and hopefully-optimized system version.
I wonder how this will be done with libposix: will the replacement be
used in any case?

Also, it sounds like libposix can be handled as a classical library
dependency, which will probably make distros feel safer, thanks to the
absence of code replication in every project that use it.

Bruce also wrote it will be versioned, which hints at some kind of
release process.

This sounds (to me) so U-turn to gnulib that I want to get
confirmation, maybe I missed something :)

-- 
Sylvain

Re: MD5 module license

[Sylvain Beucler]

On Sun, Nov 07, 2010 at 02:46:16PM +0100, Simon Josefsson wrote:
> Sylvain Beucler  writes:
> > The license of the MD5 module is documented as LGPLv2+, but the source
> > headers say it's under the GPLv2+, and that it's part of the (LGPL)
> > libc.
> >
> > What is the actual license? :)
> 
> The gnulib modules file is the canonical place, which says LGPLv2+.  For
> historical reasons the header file says GPLv2+.

Hmmm, would it make sense to update the header (possible keeping the
historical part as a comment)?

-- 
Sylvain

Re: MD5 module license

[Bruno Haible]

Sylvain Beucler wrote:
> > The gnulib modules file is the canonical place, which says LGPLv2+.  For
> > historical reasons the header file says GPLv2+.
> 
> Hmmm, would it make sense to update the header (possible keeping the
> historical part as a comment)?

The header is updated automatically when you import the file into your project,
assuming you invoke gnulib-tool with the option --lgpl or --lgpl=2.

The only place in which the header that says "GPL" is present is therefore
  - in gnulib's repository,
  - in GPLed packages that import the module.

Bruno

error.c has an unnecessary dependency on "program_name"

[Bruce Korb]

It is fairly easy to fix, just make the definition weak
and check for a NULL value before using it.  OK to push?

index ed9dba0..65f2d9d 100644
--- a/lib/error.c
+++ b/lib/error.c
@@ -106,7 +106,7 @@ char *strerror_r ();

 /* The calling program should define program_name and set it to the
name of the executing program.  */
-extern char *program_name;
+char *program_name;

 # if HAVE_STRERROR_R || defined strerror_r
 #  define __strerror_r strerror_r
@@ -300,10 +300,11 @@ error (int status, int errnum, const char *message, ...)
 (*error_print_progname) ();
   else
 {
+  char const *p = program_name ? program_name : "unknown";
 #if _LIBC
-  __fxprintf (NULL, "%s: ", program_name);
+  __fxprintf (NULL, "%s: ", p);
 #else
-  fprintf (stderr, "%s: ", program_name);
+  fprintf (stderr, "%s: ", p);
 #endif
 }

@@ -359,10 +360,11 @@ error_at_line (int status, int errnum, const char 
*file_name,
 (*error_print_progname) ();
   else
 {
+  char const *p = program_name ? program_name : "unknown";
 #if _LIBC
-  __fxprintf (NULL, "%s:", program_name);
+  __fxprintf (NULL, "%s: ", p);
 #else
-  fprintf (stderr, "%s:", program_name);
+  fprintf (stderr, "%s: ", p);
 #endif
 }

Re: libposix

[Bruce Korb]

On 11/07/10 10:45, Sylvain Beucler wrote:
> That sounds good, and this also sounds like quite a change from the
> current gnulib.

Hi Sylvain,

As you may be aware, configuring for a build can take up the
bulk of the build time for a project.  There is no intention
of preventing projects from continuing to spend all this time
every time one wants to build it.  The idea is to _allow_
projects to test for libposix and go forward if present and
stop if not.  Only libposix has to go through the long configure
process.

> As far as I understand, gnulib performs tests at ./configure time to
> decide whether to use the gnulib replacement, or rely on the
> decent-enough and hopefully-optimized system version.
> I wonder how this will be done with libposix: will the replacement be
> used in any case?

You write your project code to presume libposix is present and
then you add something like -I/usr/local/include/libposix at the
head of your include list and -L/usr/local/lib -lposix to your link.

> Also, it sounds like libposix can be handled as a classical library
> dependency, which will probably make distros feel safer, thanks to the
> absence of code replication in every project that use it.

That's the idea.

> Bruce also wrote it will be versioned, which hints at some kind of
> release process.

Along the lines of the gnulib releases.  Contrary to what is said
on www.gnu.org/software/gnulib/, there is actually a periodic release.
I forget where now.

> This sounds (to me) so U-turn to gnulib that I want to get
> confirmation, maybe I missed something :)

Not a U-turn.  An *al*ternative.  :)  - Bruce

Re: [PATCH 4/7] New module `libposix'.

[Bruce Korb]

On 10/12/10 13:43, Bruno Haible wrote:
> Hi Gary,
> 
>> Making libposix into a module makes life considerably easier.
> 
> Yes, it triggers the magic that tells gnulib-tool to omit the augmentation of
> noinst_LIBRARIES.
> 
> But I don't agree with putting the module list here. Who will keep it
> up-to-date? The maintainable solution is to use `./posix-modules`. But how?
> Either
>   a) extend gnulib-tool so that it understands
>Depends-on:
>`./posix-modules`
>  and invokes the 'posix-modules' script.
> Or
>   b) Invoke ../posix-modules in the bootstrap script of the 'libposix'
>  subdirectory.

Or:
  c) create a script that auto-replaces the Depends-on: section of
 the module/libposix file?

Thus, it has the advantage of gnulib-tool magic and it avoids
the maintenance hassle.  The bootstrap script *could* just run it.
For that matter, we have a "d":

  d) libposix gets added to modules/.gitignore and libposix/bootstrap
 generates it before invoking gnulib-tool ?  :-D

How's "d"?

Re: error.c has an unnecessary dependency on "program_name"

[Bruno Haible]

Bruce Korb wrote:
> error.c has an unnecessary dependency on "program_name"

No, it is not an "unnecessary" dependency. There is no portable way for code
in a module to determine the name of the current program. Programs that use the
'error' module must define the program_name variable and assign it a value.

> It is fairly easy to fix, just make the definition weak
> and check for a NULL value before using it.  OK to push?
> 
> index ed9dba0..65f2d9d 100644
> --- a/lib/error.c
> +++ b/lib/error.c
> @@ -106,7 +106,7 @@ char *strerror_r ();
> 
>  /* The calling program should define program_name and set it to the
> name of the executing program.  */
> -extern char *program_name;
> +char *program_name;
> ...
> +  char const *p = program_name ? program_name : "unknown";

No, this is not OK, for two reasons:
  1) It will cause a link error for all programs that define the 'program_name'
 variable, on all non-ELF platforms (mainly MacOS X and Woe32).
  2) Substituting "unknown" instead of a real program name will not help the
 end user.

Bruno

Re: libposix - is it done yet?

[Bruce Korb]

On 10/10/10 09:00, Bruno Haible wrote:
> Hi Bruce,
> 
>> > href="http://www.woofiles.com/dl-208694-BfZFVR4K-libposix2010.10.05.tar.gz";>libposix-2010.10.05.tar.gz
> 
>> The tarball rolls up to 2MB with these directories:
>>
>> libposix-2010.10.05/libposix/uniwidth
>> libposix-2010.10.05/libposix/unistr
>> libposix-2010.10.05/libposix/glthread
>> libposix-2010.10.05/glm4
>> libposix-2010.10.05/build-aux
>> libposix-2010.10.05/aclocal
> 
> IMO the unit tests should be included.

Maybe first the tests need to be gotten working:

FAIL: test-dprintf-posix2.sh
FAIL: test-fprintf-posix3.sh


>sh> exec
/bin/sh: line 5: 24795 Segmentation fault  EXEEXT='' srcdir='../../tests' 
LOCALE_FR='fr_FR' LOCALE_FR_UTF8='fr_FR.UTF-8' LOCALE_FR='fr_FR' 
LOCALE_TR_UTF8='tr_TR.UTF-8' LOCALE_FR='fr_FR' LOCALE_FR_UTF8='fr_FR.UTF-8' 
LOCALE_JA='ja_JP' LOCALE_ZH_CN='zh_CN.GB18030' LOCALE_FR_UTF8='fr_FR.UTF-8' 
LOCALE_FR='fr_FR' LOCALE_FR_UTF8='fr_FR.UTF-8' LOCALE_JA='ja_JP' 
LOCALE_ZH_CN='zh_CN.GB18030' LOCALE_FR='fr_FR' LOCALE_FR_UTF8='fr_FR.UTF-8' 
LOCALE_JA='ja_JP' LOCALE_ZH_CN='zh_CN.GB18030' LOCALE_FR='fr_FR' 
LOCALE_FR_UTF8='fr_FR.UTF-8' MAKE='make' LOCALE_FR='fr_FR' 
LOCALE_FR_UTF8='fr_FR.UTF-8' LOCALE_JA='ja_JP' LOCALE_ZH_CN='zh_CN.GB18030' 
LOCALE_FR='fr_FR' LOCALE_FR_UTF8='fr_FR.UTF-8' LOCALE_JA='ja_JP' 
LOCALE_ZH_CN='zh_CN.GB18030' LOCALE_FR='fr_FR' LOCALE_FR_UTF8='fr_FR.UTF-8' 
LOCALE_JA='ja_JP' LOCALE_ZH_CN='zh_CN.GB18030' ${dir}$tst
FAIL: test-dprintf-posix2

Program terminated with signal 11, Segmentation fault.
#0  0x2abed6e36815 in strtoll_l_internal () from /lib64/libc.so.6
(gdb) bt
#0  0x2abed6e36815 in strtoll_l_internal () from /lib64/libc.so.6
#1  0x00400914 in atoi (argc=, argv=0x7fff8299fe38)
at /usr/include/stdlib.h:286
#2  main (argc=, argv=0x7fff8299fe38)
at ../../tests/test-dprintf-posix2.c:76
(gdb) f 2
#2  main (argc=, argv=0x7fff8299fe38)
at ../../tests/test-dprintf-posix2.c:76
76arg = atoi (argv[1]);
(gdb) p argv[1]
$1 = 0x0
(gdb) list
71limit.rlim_cur = limit.rlim_max;
72if (setrlimit (RLIMIT_AS, &limit) < 0)
73  return 77;
74  #endif
75
76arg = atoi (argv[1]);
77if (arg == 0)
78  {
79void *memory = malloc (MAX_ALLOC_TOTAL);
80if (memory == NULL)

Maybe change line 76:

  arg = argv[1] ? atoi (argv[1]) : 0;

Re: [gnulib] printf for plibc

[Bruno Haible]

Hi Nils,

Nils Durner wrote:
> ich würde gerne die printf Implementierung von gnulib in plibc (libc für
> Windows) kopieren, damit wir sie für GNUnet, GNU libextractor & Co
> benutzen können.
> Ist es für Dich okay, wenn ich Deinen Code in die der LGPL unterliegende
> plibc kopiere?

[Nils is asking whether he can use gnulib's printf implementation for plibc.]

I'm CCing bug-gnulib because Paul Eggert, Eric Blake, and Jim Meyering also
contributed to it.

plibc  appears to be under LGPLv2+.

The printf implementation in gnulib (modules 'printf-posix', 'fprintf-posix',
and similar) are under LGPLv3+. Part of the the code (lib/vasnprintf.c) is
under LGPLv2+, but other parts (the modules 'fpucw', 'isnanl-nolibm',
'frexpl-nolibm', ...) are under LGPLv3+.

You can include this code in your plibc if, at the same time, you change
the license of plibc from LGPLv2+ to LGPLv3+.

Technically, it would be a lot of work to do this by hand. The easiest way
is to invoke gnulib-tool through
  $ gnulib-tool --import [some other options] --lgpl \
fprintf-posix printf-posix snprintf-posix sprintf-posix \
vfprintf-posix vprintf-posix vsnprintf-posix vsprintf-posix

Please read the gnulib manual if you want to know more about how to integrate
parts of gnulib into your package.

Note also that the printf of gnulib assumes a rudimentary working printf in the
system library. It delegates directives like %d, %u, or %s to the system's
printf.

Bruno

Re: error.c has an unnecessary dependency on "program_name"

[Bruce Korb]

On 11/07/10 12:40, Bruno Haible wrote:
> No, this is not OK, for two reasons:
>   1) It will cause a link error for all programs that define the 
> 'program_name'
>  variable, on all non-ELF platforms (mainly MacOS X and Woe32).

Not having MacOS or Woe32, I couldn't know.

>   2) Substituting "unknown" instead of a real program name will not help the
>  end user.

Seg faulting is even less friendly.  Perhaps "(NULL)" as some
libraries do?  One could go grubbing around in /proc/$$/exe
but I'm trying to keep stuff out of libposix that isn't posix.
If it isn't possible, it isn't possible.  Still, it does not seem
like removing the hard dependency should be all that hard.

The problem being is that we have two scenarios for libposix clients:
1. one that defines program_invocation_name
2. one that does not
How do I cope?

I am actually more interested in the two printf test failures.
I've beat my head on it for a bit.It seems that if I invoke the
test correctly (TESTS=test-dprintf-posix2.sh with the ".sh" suffix),
the failure ultimately boils down to the program exiting with
an exit code of "1", which might be an allocation failure or a
dprintf failure.  There is no visible output, so I cannot say.

Thanks - Bruce

unprefixed header guards

[Bruce Korb]

As of now, here are the files that get installed via "libposix":

$ find * -type f
usr/local/lib/libposix.a
usr/local/lib/libposix.so.0.0.0
usr/local/lib/libposix.la
[[a mess of includes]]
usr/local/libexec/libposix/pt_chown

And here are the headers that do not prefix an "ifndef"
with "_LIBPOSIX_":

$ ls -1 $(allbut usr/local/include/*.h - $(
> egrep -l '#ifndef _LIBPOSIX_' usr/local/include/*.h) )
usr/local/include/arg-nonnull.h
usr/local/include/iconv_open-aix.h
usr/local/include/iconv_open-hpux.h
usr/local/include/iconv_open-irix.h
usr/local/include/iconv_open-osf.h
usr/local/include/iconv_open-solaris.h
usr/local/include/inttypes.h
usr/local/include/unitypes.h
usr/local/include/unused-parameter.h
usr/local/include/warn-on-use.h

The "iconv_open" ones are private and clearly okay.
However, arg-nonnull.h:
#ifndef _GL_ARG_NONNULL

and inttypes.h looks very strange:
/* The definition of _GL_WARN_ON_USE is copied here.  */
#ifndef _GL_WARN_ON_USE

unitypes.h:
#ifndef _UNITYPES_H
#define _UNITYPES_H

unused-parameter.h:
#ifndef _GL_UNUSED_PARAMETER

and warn-on-use uses _GL_WARN_ON_USE, per the copied text in inttypes.h

I don't know the plan here, but it isn't consistent.

Thanks - Bruce

Re: libposix - is it done yet?

[Bruno Haible]

Bruce Korb wrote:
> Maybe first the tests need to be gotten working:
> 
> FAIL: test-dprintf-posix2.sh
> FAIL: test-fprintf-posix3.sh
> 
> 
> >sh> exec
> /bin/sh: line 5: 24795 Segmentation fault  EXEEXT='' srcdir='../../tests' 
> LOCALE_FR='fr_FR' LOCALE_FR_UTF8='fr_FR.UTF-8' LOCALE_FR='fr_FR' 
> LOCALE_TR_UTF8='tr_TR.UTF-8' LOCALE_FR='fr_FR' LOCALE_FR_UTF8='fr_FR.UTF-8' 
> LOCALE_JA='ja_JP' LOCALE_ZH_CN='zh_CN.GB18030' LOCALE_FR_UTF8='fr_FR.UTF-8' 
> LOCALE_FR='fr_FR' LOCALE_FR_UTF8='fr_FR.UTF-8' LOCALE_JA='ja_JP' 
> LOCALE_ZH_CN='zh_CN.GB18030' LOCALE_FR='fr_FR' LOCALE_FR_UTF8='fr_FR.UTF-8' 
> LOCALE_JA='ja_JP' LOCALE_ZH_CN='zh_CN.GB18030' LOCALE_FR='fr_FR' 
> LOCALE_FR_UTF8='fr_FR.UTF-8' MAKE='make' LOCALE_FR='fr_FR' 
> LOCALE_FR_UTF8='fr_FR.UTF-8' LOCALE_JA='ja_JP' LOCALE_ZH_CN='zh_CN.GB18030' 
> LOCALE_FR='fr_FR' LOCALE_FR_UTF8='fr_FR.UTF-8' LOCALE_JA='ja_JP' 
> LOCALE_ZH_CN='zh_CN.GB18030' LOCALE_FR='fr_FR' LOCALE_FR_UTF8='fr_FR.UTF-8' 
> LOCALE_JA='ja_JP' LOCALE_ZH_CN='zh_CN.GB18030' ${dir}$tst
> FAIL: test-dprintf-posix2
> 
> Program terminated with signal 11, Segmentation fault.
> #0  0x2abed6e36815 in strtoll_l_internal () from /lib64/libc.so.6
> (gdb) bt
> #0  0x2abed6e36815 in strtoll_l_internal () from /lib64/libc.so.6
> #1  0x00400914 in atoi (argc=, 
> argv=0x7fff8299fe38)
> at /usr/include/stdlib.h:286
> #2  main (argc=, argv=0x7fff8299fe38)
> at ../../tests/test-dprintf-posix2.c:76
> (gdb) f 2
> #2  main (argc=, argv=0x7fff8299fe38)
> at ../../tests/test-dprintf-posix2.c:76
> 76arg = atoi (argv[1]);
> (gdb) p argv[1]
> $1 = 0x0
> 
> Maybe change line 76:
> 
>   arg = argv[1] ? atoi (argv[1]) : 0;

When you follow test-dprintf-posix2.sh, you see that the test consists in
running test-dprintf-posix2 twice, once with argument 0, and once with
argument 1. Are you saying then in gdb, when you do
  (gdb) run 0
or
  (gdb) run 1
then argv[1] ends up being NULL?

Bruno

Re: [PATCH 4/7] New module `libposix'.

[Bruno Haible]

Bruce Korb wrote:
> > Who will keep it
> > up-to-date? The maintainable solution is to use `./posix-modules`. But how?
> > Either ...
> >   b) Invoke ../posix-modules in the bootstrap script of the 'libposix'
> >  subdirectory.
> 
> Or:
>   c) create a script that auto-replaces the Depends-on: section of
>  the module/libposix file?
> 
> Thus, it has the advantage of gnulib-tool magic and it avoids
> the maintenance hassle.  The bootstrap script *could* just run it.
> For that matter, we have a "d":
> 
>   d) libposix gets added to modules/.gitignore and libposix/bootstrap
>  generates it before invoking gnulib-tool ?  :-D
> 
> How's "d"?

Yes, why not? You don't even need to fuss with modules/.gitignore. Just
remove modules/libposix when you're done.

Or create this modules/libposix in a temporary directory:
  $ mkdir tmp
  $ mkdir tmp/modules
  $ func_create_libposix_module > tmp/modules/libposix
  ...
  $ gnulib-tool ... --local-dir=tmp ...
  ...
  $ rm -rf tmp

Bruno

Re: error.c has an unnecessary dependency on "program_name"

[Bruno Haible]

Hi Bruce,

> >   1) It will cause a link error for all programs that define the 
> > 'program_name'
> >  variable, on all non-ELF platforms (mainly MacOS X and Woe32).

... and HP-UX, which also is a non-ELF platform.

> Not having MacOS or Woe32, I couldn't know.

There is some code for determining the program's name ad-hoc for MacOS X
and Woe32 in progreloc.c. But for HP-UX, I don't know...

If you don't have access to these systems and no one else find a good
solution, then you will likely have to document: "Before using libposix,
you have to invoke set_program_name(argv[0]);" and add the module 'progname'
to libposix. I think that's an acceptable compromise: many users of gnulib
have done the same for the last 7 years.

> >   2) Substituting "unknown" instead of a real program name will not help the
> >  end user.
> 
> Seg faulting is even less friendly.

A seg fault is a very clear hint to the developer that he needs to fix up his
code. Which IMO is the only good solution if a programmer has not defined
program_name.

Bruno

Re: unprefixed header guards

[Bruno Haible]

Bruce Korb wrote:
> And here are the headers that do not prefix an "ifndef"
> with "_LIBPOSIX_":
> 
> $ ls -1 $(allbut usr/local/include/*.h - $(
> > egrep -l '#ifndef _LIBPOSIX_' usr/local/include/*.h) )
> usr/local/include/arg-nonnull.h
> usr/local/include/iconv_open-aix.h
> usr/local/include/iconv_open-hpux.h
> usr/local/include/iconv_open-irix.h
> usr/local/include/iconv_open-osf.h
> usr/local/include/iconv_open-solaris.h
> usr/local/include/inttypes.h
> usr/local/include/unitypes.h
> usr/local/include/unused-parameter.h
> usr/local/include/warn-on-use.h

The only file in this list that contains public API is inttypes.h.
The others should not be installed in a public location.

The 'Include:' section of the module descriptions tells you about
this. Files that are not mentioned in the 'Include:' section of
any module description are private.

Bruno

Re: [gnulib] printf for plibc

[Nils Durner]

Hi Bruno,

okay, thanks a lot.


Best,

Nils

fdopendir failure on MacOS X with GNU tar 1.25

[Paul Eggert]

(This is following up on recent bug reports sent to bug-tar:



.

but it appears to be a gnulib bug so I'm CC'ing this to bug-gnulib.)

On 11/07/2010 09:49 AM, tsteven4 wrote:

> I attached the output of "sudo dtruss -n tar -f -a > &
> tar125_dtruss.txt" while running "make check TESTSUITEFLAGS=37".

Thanks for sending that.  In looking through the dtruss output I see a
bug in gnulib's fdopendir.c implementation: when fdopendir(N) is
invoked, and N is the maximum openable file descriptor, and there are
some unopened file descriptors less than N, then fdopendir first uses
'dup' to consume these unopened file descriptors, and then invokes
save_cwd to save the working directory.  But save_cwd consumes a file
descriptor, so it fails with errno == EMFILE.  The fix is to invoke
save_cwd before invoking 'dup'.

Could you please try the following patch, which implements this fix?
I am enclosing a copy of the new fdopendir.c; perhaps it'd be easiest
if you simply copied this new version over tar-1.25/gnu/fdopendir.c,
and then rebuilt 'tar'.

Thanks.

>From 83fb034e8c087a7278c0d3a5686d9c384afa34b8 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sun, 7 Nov 2010 21:58:54 -0800
Subject: [PATCH] fdopendir: fix bug on MacOS X when low on file descriptors

* lib/fdopendir.c (REPLACE_FCHDIR): #define to 0 if not defined.
(fdopendir_with_dup, fd_clone_opendir): Now have extra CWD arg.
All callers changed.
(fdopendir): Invoke save_cwd at the top level, not after using
multiple dup() calls to use up file descriptors.  Then retry
fdopendir_with_dup.  This avoids failure with EMFILE if FD is 1
less than the maximum number of open file descriptors, because
save_cwd fails with errno == EMFILE.  Problem reported by tsteven4
on Mac OS X 10.6.4 for tar 1.24


and for tar 1.25
.
---
 ChangeLog   |   18 
 lib/fdopendir.c |  124 ++
 2 files changed, 78 insertions(+), 64 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 4eb90a3..4d9c4ea 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,21 @@
+2010-11-07  Paul Eggert  
+
+   fdopendir: fix bug on MacOS X when low on file descriptors
+
+   * lib/fdopendir.c (REPLACE_FCHDIR): #define to 0 if not defined.
+   (fdopendir_with_dup, fd_clone_opendir): Now have extra CWD arg.
+   All callers changed.
+   (fdopendir): Invoke save_cwd at the top level, not after using
+   multiple dup() calls to use up file descriptors.  Then retry
+   fdopendir_with_dup.  This avoids failure with EMFILE if FD is 1
+   less than the maximum number of open file descriptors, because
+   save_cwd fails with errno == EMFILE.  Problem reported by tsteven4
+   on Mac OS X 10.6.4 for tar 1.24
+   
+   
+   and for tar 1.25
+   .
+
 2010-11-07  Bruno Haible  
 
vasnprintf: Support I flag on glibc systems.
diff --git a/lib/fdopendir.c b/lib/fdopendir.c
index 4d2935f..e565087 100644
--- a/lib/fdopendir.c
+++ b/lib/fdopendir.c
@@ -33,12 +33,16 @@
 #  include "dirent--.h"
 # endif
 
-static DIR *fdopendir_with_dup (int, int);
-static DIR *fd_clone_opendir (int);
+# ifndef REPLACE_FCHDIR
+#  define REPLACE_FCHDIR 0
+# endif
+
+static DIR *fdopendir_with_dup (int, int, struct saved_cwd const *);
+static DIR *fd_clone_opendir (int, struct saved_cwd const *);
 
 /* Replacement for POSIX fdopendir.
 
-   First, try to simulate it via opendir ("/proc/self/fd/FD").  Failing
+   First, try to simulate it via opendir ("/proc/self/fd/...").  Failing
that, simulate it by using fchdir metadata, or by doing
save_cwd/fchdir/opendir(".")/restore_cwd.
If either the save_cwd or the restore_cwd fails (relatively unlikely),
@@ -61,7 +65,24 @@ static DIR *fd_clone_opendir (int);
 DIR *
 fdopendir (int fd)
 {
-  return fdopendir_with_dup (fd, -1);
+  DIR *dir = fdopendir_with_dup (fd, -1, NULL);
+
+  if (! REPLACE_FCHDIR && ! dir)
+{
+  int saved_errno = errno;
+  if (EXPECTED_ERRNO (saved_errno))
+{
+  struct saved_cwd cwd;
+  if (save_cwd (&cwd) != 0)
+openat_save_fail (errno);
+  dir = fdopendir_with_dup (fd, -1, &cwd);
+  saved_errno = errno;
+  free_cwd (&cwd);
+  errno = saved_errno;
+}
+}
+
+  return dir;
 }
 
 /* Like fdopendir, except that if OLDER_DUPFD is not -1, it is known
@@ -70,9 +91,13 @@ fdopendir (int fd)
function 

Re: error.c has an unnecessary dependency on "program_name"

[Bruce Korb]

On 11/07/10 15:55, Bruno Haible wrote:
>> Seg faulting is even less friendly.
> 
> A seg fault is a very clear hint to the developer that he needs to fix up his
> code. Which IMO is the only good solution if a programmer has not defined
> program_name.

But it would only be encountered if the programmer triggers
an issue that calls one of the faulting error functions.
The programmer might hit it, or his customer might.  You never know.
But that is an issue for another day.  :)