Re: error compiling regex gnulib module with pgcc compiler

[Ralf Wildenhues]

Hi Paul,

* Paul Eggert wrote on Thu, Jan 05, 2006 at 07:40:26PM CET:
> Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> 
> > This is pgcc 6.0-8 64-bit target on x86-64 Linux, but as indicated
> > above, the issue is present in 5.2-1 as well.
> 
> Thanks for checking that.  Can you please run the following
> program on that platform and send us the output?  If it outputs
> "preprocessor thinks BITSET_WORD_BITS = 64", then we have an
> obvious fix to regex_internal.h.  Thanks.

Yes, it outputs:

| ULONG_MAX = 18446744073709551615
| sizeof(ulong) = 8
| 1
| BITSET_WORD_BITS = 64
| preprocessor thinks BITSET_WORD_BITS = 64

Cheers,
Ralf


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

another warning in localcharset.c

[Werner LEMBERG]

During compilation with gcc 3.3.3 I get

  localcharset.c:110: warning: function declaration isn't a prototype

maybe the `STATIC' hack as used for locale_charset is needed too...


Werner


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

localcharset needs HAVE_DECL_GETC_UNLOCKED

[Werner LEMBERG]

[CVS 2006-01-06]

The file localcharset.c asks for the preprocessor symbol
HAVE_DECL_GETC_UNLOCKED which doesn't get defined in the m4 files
listed in modules/localcharset.


Werner


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

Re: error compiling regex gnulib module with pgcc compiler

[Claudio Fontana]

--- Ralf Wildenhues <[EMAIL PROTECTED]> wrote: 

> Hi Paul,
> 
> > Paul Eggert wrote on Thu, Jan 05, 2006:
> > Thanks for checking that.  Can you please run the
> following
> > program on that platform and send us the output? 
> If it outputs
> > "preprocessor thinks BITSET_WORD_BITS = 64", then
> we have an
> > obvious fix to regex_internal.h.  Thanks.
> 
> Yes, it outputs:
> 
> | ULONG_MAX = 18446744073709551615
> | sizeof(ulong) = 8
> | 1
> | BITSET_WORD_BITS = 64
> | preprocessor thinks BITSET_WORD_BITS = 64

Thanks, I have already included the fix (attached) to
regex_internal.h in the idutils copy of the gnulib
sources.

> Cheers,
> Ralf

Claudio


Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 

regex_internal.h.pgcc-workaround.udiff
Description: 3981055952-regex_internal.h.pgcc-workaround.udiff
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: version-etc upgrade to 2006

[Jim Meyering]

Paul Eggert <[EMAIL PROTECTED]> wrote:
> I installed this:
>   Sync from coreutils.

Thanks for all of the merge work!


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

Re: changes for openat, mkdir-p, lchmod

[Jim Meyering]

It looks like I've subverted things a little: the lib/ChangeLog entry for
fts.c and openat.[ch] below correspond to a change I haven't yet committed.
I think it's complete, but it's rather ambitious, and requires changes
(albeit small) in every program that uses fts.  So I'm taking my time.

I committed it (only the ChangeLog entry) by mistake when I made the
version-etc.c change.  I'll back it out of coreutils and gnulib now.
Sorry about that.

Paul Eggert <[EMAIL PROTECTED]> wrote:
> I installed this to sync gnulib from coreutils.  This is the biggest
> change hunk; the changes all tend to depend on each other.  It's still
> mutating but I think this snapshot will work with other programs (it
> works with GNU tar, anyway).
>
> The lchmod business is a bit tricky, since it uses chmod as a
> substitute for lchmod.  Callers are supposed to check that files are
> not symbolic links before using lchmod, which obviously leads to race
> conditions, but that's the best we can do on hosts that lack lchmod.
>
> 2006-01-09  Paul Eggert  <[EMAIL PROTECTED]>
...
> 2006-01-09  Jim Meyering  <[EMAIL PROTECTED]>
>
>   Sync from coreutils.
>
>   Rewrite fts.c not to change the current working directory,
>   by using openat, fstatat, fdopendir, etc..
>
>   * lib/fts.c [! _LIBC]: Include "openat.h", "unistd--.h", and 
> "fcntl--.h".
>   [_LIBC] (fchdir): Don't undef or define; no longer used.
>   (FCHDIR): Define in terms of cwd_advance_fd rather than fchdir.
>   Now, this `function' always succeeds, and consumes its file descriptor
>   parameter -- so callers must not close such FDs.  Update callers.
>   (diropen_fd, opendirat, cwd_advance_fd): New functions.
>   (diropen): Add parameter, SP.  Adjust all callers.
>   Implement using diropen_fd, rather than open.
>   (fts_open): Initialize new member, fts_cwd_fd.
>   Remove fts_rft-setting code.
>   (fts_close): Close fts_cwd_fd, if necessary.
>   (__opendir2): Define in terms of opendir or opendirat,
>   depending on whether the FST_NOCHDIR flag is set.
>   (fts_build): Since fts_safe_changedir consumes its FD, and since
>   this code must do `closedir(dirp)', dup the dirfd(dirp) argument,
>   and close the dup'd file descriptor upon failure.
>   (fts_stat): Use fstatat(...AT_SYMLINK_NOFOLLOW) in place of lstat.
>   (fts_safe_changedir): Tweak semantics to reflect that this function
>   now calls cwd_advance_fd and hence consumes its FD argument.
>   * lib/fts_.h [struct FTS] (fts_cwd_fd): New member.
>   (fts_rft): Remove now-unused member.
>
>   * lib/openat.c (fchownat): New function.
>   * lib/openat.h (fchmodat, fchownat): Declare.
>   (chmodat, lchmodat): Define convenience functions.
>   (chownat, lchownat): Likewise.
...


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

Re: [bug-gnulib] argp: output formatting, and argp_child interface.

[Paul Knowles]

>Bruno Haible replied on 2006-01-09:
>Paul Knowles wrote on 2005-12-15:
>> *** Problem #1
>> struct argp{
>>   ...
>>   /* A vector of argp_children structures, terminated by a member with a 0
>>  argp field, pointing to child argps should be parsed with this one.  Any
>>  conflicts are resolved in favor of this argp, or early argps in the
>>  CHILDREN list.  This field is useful if you use libraries that supply
>>  their own argp structure, which you want to use in conjunction with your
>>  own.  */
>>   __const struct argp_child *children;
>>   ...
>> }
>> 
>> In my opinion, much better would be 
>> struct argp_child **children;
>> for the reason that multiparser structures can then have an easy to
>> use, scalable, interface.  By adding a function to add children, much
>> of the complexity of the multiparser setup will go away.
>
>Sorry, I don't understand. The argp facility is meant for a set of options
>known when the program starts. (Otherwise how do you manage to write a
>manual page for the program?) Do you mean to add options dynamically?

Yes, I will agree that the ``options are known when the
program starts'', but, why should the options that apply to
the functions contained in file foo.c not be contained in
that file?  For a small project with a few files, putting
all the help and options parsing in one central file is fine.
My project has some 6 different frequency estimators, each
with different configuration parameters, and it is a royal
pain to have to touch two different files just to add one
modification to one suboption of one estimator (the 34
different windowing functions are just so much fun too!).
Since the group of people using the code will also want to
be able to add estimators, I need to make the interface very
simple: they add one _one_ pointer to one array in main(), and
all the other work for options and so on must happen
transparently.  ``struct argp_child *'' makes my job harder
in that respect.

So, the change to a struct argp_child ** would clean up the
programming interface for adding suboptions to the options list.
Options can be easily kept with the code they control, and a
simple list builder can initializer the parser array before
argument parsing.  

This is not just my problem: libbow has faced the same thing
(http://www.cs.cmu.edu/~mccallum/bow/) and solved it via:

bow>> #define MAX_NUM_CHILDREN 100
bow>> struct argp_child bow_argp_children[MAX_NUM_CHILDREN] =
bow>> {
bow>>   {
bow>> &bow_argp,  /* the argp structure */
bow>> 0,  /* flags for child */
bow>> "Libbow options",   /* optional header */
bow>> 999 /* group (general lib flags at end of 
help)*/
bow>>   },
bow>>   {0}
bow>> };
bow>> 
bow>> /* The number of children already initialized in the const assignment 
above. */
bow>> static int bow_argp_children_length = 1;
bow>> 
bow>> /* Add the options in CHILD to the list of command-line options. */
bow>> void
bow>> bow_argp_add_child (struct argp_child *child)
bow>> {
bow>>   assert (bow_argp_children_length+1 < MAX_NUM_CHILDREN);
bow>>   memcpy (bow_argp_children + bow_argp_children_length,
bow>>   child,
bow>>   sizeof (struct argp_child));
bow>>   bow_argp_children_length++;
bow>> #if 1
bow>>   memset (bow_argp_children + bow_argp_children_length,
bow>>   0, sizeof (struct argp_child));
bow>> #endif
bow>> }

It works (provided the uses have no more than 98 children to
add), but for me, the adding of arbitrary number of parser
children is code that really belongs to the argp API, and
shouldn't be kludged together by each argp user who faces
this problem.  It is also ugly that the solution requires
_two_ copies of each child struct, the initializer, and the
working copy in the array.


>> *** Problem #2
>> Word wrapping should look at the COLUMNS environment variable to
>> determine word wrap unless rmargin=N was explicitly set by the user in 
>> ARGP_HELP_FMT.  It is silly that help text gets garbled and squashed
>> up into 79 columns on my 110 column xterms and that the resizing is
>> not automagic.
>
>I agree. But you can get the desired behaviour yourself: Put the value
>of getenv("COLUMNS") into ARGP_HELP_FMT.

I understand that, and that's what I will probably do, but I
think you will agree that passing something to the
environment, so that another part of the _same_ program can
read it out of the environment is ugly, and I've always been
well served by the hyphothesis ugly code == fragily easily
broken buggy code.

>> ***  Problem 3;
>>  I believe I have also stumbled on an output formatting problem, but
>> the code to duplicate a test case of this is not yet ready.
>Can you provide the test case, please?

If I can find the time to make a small test case that
reproduces the problem, i will.  Teaching semester is on at
the moment however,

thanks for your comments,

Paul Knowles.   phone: 4

Re: use of -fno-common on Darwin

[Bruno Haible]

Paul Eggert wrote:
> "Peter O'Gorman" <[EMAIL PROTECTED]> writes:
> > getprogname(3), if it exists, can be used as well as other
> > alternatives (e.g. argv[0]).
>
> Thanks, I wasn't aware of the BSD getprogname until now.

Me too.

> How about this proposal?
>
> * Change the progname module to use the BSD getprogname naming
>   convention.  No sense reinventing the wheel.  That way, programs can
>   simply use the system-defined functions on BSD.
>
> * Rewrite the other gnulib code to use the new convention.
>
> * Ask gnulib users to switch to the new convention.

Yes, that's the most sensible thing to do. If there are no objections,
I will change the 'progname' module accordingly.

Bruno



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

bug in memcoll module

[Bruno Haible]

Hi Paul,

This commit

2002-12-31  Paul Eggert  <[EMAIL PROTECTED]>

* memcoll.m4 (gl_MEMCOLL): Require AC_FUNC_MEMCMP.

causes a gnulib-tool error:

$ ./gnulib-tool --create-testdir --dir=testdir memcoll
Module list with included dependencies:
  memcoll
File list:
  lib/memcoll.c
  lib/memcoll.h
  m4/memcoll.m4
  m4/onceonly_2_57.m4
executing autoreconf --force --install
configure.ac: installing `build-aux/install-sh'
configure.ac: installing `build-aux/missing'
lib/Makefile.am:17: required file `lib/memcmp.c' not found
autoreconf: automake failed with exit status: 1

Actually, memcoll.m4 should require gl_FUNC_MEMCMP, not AC_FUNC_MEMCMP,
since it is meant to use the memcmp.c replacement.

IMO, the fix depends whether you trust memcmp() these days.
If yes, then do not require AC_FUNC_MEMCMP.
If no, then make a dependency from 'memcoll' to 'memcmp'. And then you don't
   need to require AC_FUNC_MEMCMP either, since the gnulib-tool
   dependency mechanism will take care of invoking gl_FUNC_MEMCMP.

In either case, the appended patch should be part of the fix.

Bruno


*** m4/memcoll.m4.bak   2005-03-22 15:39:12.0 +0100
--- m4/memcoll.m4   2006-01-08 15:05:26.0 +0100
***
*** 1,5 
! # memcoll.m4 serial 5
! dnl Copyright (C) 2002, 2003, 2005 Free Software Foundation, Inc.
  dnl This file is free software; the Free Software Foundation
  dnl gives unlimited permission to copy and/or distribute it,
  dnl with or without modifications, as long as this notice is preserved.
--- 1,5 
! # memcoll.m4 serial 6
! dnl Copyright (C) 2002, 2003, 2005, 2006 Free Software Foundation, Inc.
  dnl This file is free software; the Free Software Foundation
  dnl gives unlimited permission to copy and/or distribute it,
  dnl with or without modifications, as long as this notice is preserved.
***
*** 10,15 
AC_LIBOBJ([memcoll])
  
dnl Prerequisites of lib/memcoll.c.
-   AC_REQUIRE([AC_FUNC_MEMCMP])
AC_FUNC_STRCOLL
  ])
--- 10,14 




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

bug in 'iconvme' module

[Bruno Haible]

Simon,

On MacOS X with GNU libiconv module, the iconvme module exhibits a build
failure:

Making all in lib
make  all-am
gcc -DHAVE_CONFIG_H -I. -I../../../megatestdir/iconvme/lib -I.. -g -O2 -c 
../../../megatestdir/iconvme/lib/iconvme.c
../../../megatestdir/iconvme/lib/iconvme.c: In function `iconv_alloc':
../../../megatestdir/iconvme/lib/iconvme.c:134: warning: passing arg 2 of 
`libiconv' from incompatible pointer type
rm -f libgnu.a
ar cru libgnu.a iconvme.o -liconv
ar: -liconv: No such file or directory
make[4]: *** [libgnu.a] Error 1
make[4]: Target `all-am' not remade because of errors.
make[3]: *** [all] Error 2

IMO you need to add $(LTLIBICONV) to lib_LDFLAGS, not lib_LIBADD.
And also, use $(LIBICONV) instead of $(LTLIBICONV) when libtool is not used.
That's why you introduced GL_COND_LIBTOOL conditional, no?

Bruno




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

use of autoreconf requires AM_GNU_GETTEXT_VERSION

[Bruno Haible]

Hi,

The use of autoreconf, introduced on 2004-09-18, causes
./gnulib-tool --create-testdir --dir=/dev/shm/testdir gettext
to fail:
autoreconf: configure.ac: AM_GNU_GETTEXT is used, but not AM_GNU_GETTEXT_VERSION

I'm committing this fix.


2006-01-07  Bruno Haible  <[EMAIL PROTECTED]>

* modules/gettext (configure.ac): Add an invocation of
AM_GNU_GETTEXT_VERSION. Needed since autoreconf is used by gnulib-tool.

*** modules/gettext.bak 2005-09-15 22:36:09.0 +0200
--- modules/gettext 2006-01-07 19:29:53.0 +0100
***
*** 36,41 
--- 36,42 
  
  configure.ac:
  AM_GNU_GETTEXT([external])
+ AM_GNU_GETTEXT_VERSION([0.14.5])
  
  Makefile.am:
  




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

Re: [bug-gnulib] localcharset needs HAVE_DECL_GETC_UNLOCKED

[Bruno Haible]

Werner LEMBERG wrote:
> The file localcharset.c asks for the preprocessor symbol
> HAVE_DECL_GETC_UNLOCKED which doesn't get defined in the m4 files
> listed in modules/localcharset.

I committed this fix:

2006-01-10  Bruno Haible  <[EMAIL PROTECTED]>

* localcharset.m4 (gl_LOCALCHARSET): Also test for getc_unlocked.
Reported by Werner Lemberg <[EMAIL PROTECTED]>.

*** localcharset.m4 18 Jan 2005 13:07:56 -  1.3
--- localcharset.m4 10 Jan 2006 13:55:33 -
***
*** 1,5 
! # localcharset.m4 serial 2
! dnl Copyright (C) 2002 Free Software Foundation, Inc.
  dnl This file is free software; the Free Software Foundation
  dnl gives unlimited permission to copy and/or distribute it,
  dnl with or without modifications, as long as this notice is preserved.
--- 1,5 
! # localcharset.m4 serial 3
! dnl Copyright (C) 2002, 2004, 2006 Free Software Foundation, Inc.
  dnl This file is free software; the Free Software Foundation
  dnl gives unlimited permission to copy and/or distribute it,
  dnl with or without modifications, as long as this notice is preserved.
***
*** 9,14 
--- 9,15 
dnl Prerequisites of lib/localcharset.c.
AC_CHECK_HEADERS_ONCE(stddef.h stdlib.h string.h)
AC_REQUIRE([AM_LANGINFO_CODESET])
+   AC_CHECK_DECLS_ONCE(getc_unlocked)
AC_CHECK_FUNCS_ONCE(setlocale)
  
dnl Prerequisites of the lib/Makefile.am snippet.



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

Re: [bug-gnulib] another warning in localcharset.c

[Bruno Haible]

Werner Lemberg wrote:
> During compilation with gcc 3.3.3 I get
>
>   localcharset.c:110: warning: function declaration isn't a prototype

OK, should now be fixed in gnulib CVS:


2006-01-10  Bruno Haible  <[EMAIL PROTECTED]>

  * localcharset.c: Update from GNU gettext.

*** localcharset.c  14 May 2005 06:03:58 -  1.20
--- localcharset.c  10 Jan 2006 13:49:31 -
***
*** 1,6 
  /* Determine a canonical name for the current locale's character encoding.
  
!Copyright (C) 2000-2004 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
--- 1,6 
  /* Determine a canonical name for the current locale's character encoding.
  
!Copyright (C) 2000-2006 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
***
*** 106,112 
  
  /* Return a pointer to the contents of the charset.alias file.  */
  static const char *
! get_charset_aliases ()
  {
const char *cp;
  
--- 106,112 
  
  /* Return a pointer to the contents of the charset.alias file.  */
  static const char *
! get_charset_aliases (void)
  {
const char *cp;
  
***
*** 248,253 
--- 248,254 
   "CP1361" "\0" "JOHAB" "\0"
   "CP20127" "\0" "ASCII" "\0"
   "CP20866" "\0" "KOI8-R" "\0"
+  "CP20936" "\0" "GB2312" "\0"
   "CP21866" "\0" "KOI8-RU" "\0"
   "CP28591" "\0" "ISO-8859-1" "\0"
   "CP28592" "\0" "ISO-8859-2" "\0"
***
*** 258,264 
   "CP28597" "\0" "ISO-8859-7" "\0"
   "CP28598" "\0" "ISO-8859-8" "\0"
   "CP28599" "\0" "ISO-8859-9" "\0"
!  "CP28605" "\0" "ISO-8859-15" "\0";
  # endif
  #endif
  
--- 259,272 
   "CP28597" "\0" "ISO-8859-7" "\0"
   "CP28598" "\0" "ISO-8859-8" "\0"
   "CP28599" "\0" "ISO-8859-9" "\0"
!  "CP28605" "\0" "ISO-8859-15" "\0"
!  "CP38598" "\0" "ISO-8859-8" "\0"
!  "CP51932" "\0" "EUC-JP" "\0"
!  "CP51936" "\0" "GB2312" "\0"
!  "CP51949" "\0" "EUC-KR" "\0"
!  "CP51950" "\0" "EUC-TW" "\0"
!  "CP54936" "\0" "GB18030" "\0"
!  "CP65001" "\0" "UTF-8" "\0";
  # endif
  #endif
  
***
*** 278,284 
  STATIC
  #endif
  const char *
! locale_charset ()
  {
const char *codeset;
const char *aliases;
--- 286,292 
  STATIC
  #endif
  const char *
! locale_charset (void)
  {
const char *codeset;
const char *aliases;



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

work around automake error

[Bruno Haible]

Hi,

./gnulib-tool --create-testdir --dir=/dev/shm/testdir --with-tests gettext
gives an error:
configure.ac: AM_GNU_GETTEXT used but SUBDIRS not defined
autoreconf: automake failed with exit status: 1

I'm committing this fix.

2006-01-07  Bruno Haible  <[EMAIL PROTECTED]>

* gnulib-tool (func_emit_tests_Makefile_am): Emit an empty SUBDIR
variable.
Needed to avoid an automake error regarding the 'gettext' module.

*** gnulib-tool.bak 2006-01-07 16:41:09.0 +0100
--- gnulib-tool 2006-01-07 19:41:07.0 +0100
***
*** 748,753 
--- 748,757 
echo
echo "ACLOCAL_AMFLAGS = -I ${testsbase_inverse}/${m4base}"
echo
+   # Nothing is being added to SUBDIRS; nevertheless the existence of this
+   # variable is needed to avoid an error from automake:
+   #   "AM_GNU_GETTEXT used but SUBDIRS not defined"
+   echo "SUBDIRS ="
echo "TESTS ="
echo "TESTS_ENVIRONMENT ="
echo "noinst_PROGRAMS ="




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

__const

[Bruno Haible]

Hi,

I think it's time to get rid of __const. gnulib assumes an ANSI C compiler,
glibc does as well. The following glibc public header files already assume
an ANSI C compiler that groks 'const':

/usr/include/argp.h
/usr/include/assert.h
/usr/include/error.h
/usr/include/fstab.h
/usr/include/fts.h
/usr/include/gconv.h
/usr/include/getopt.h
/usr/include/libio.h
/usr/include/link.h
/usr/include/netdb.h
/usr/include/obstack.h
/usr/include/regex.h
/usr/include/regexp.h
/usr/include/resolv.h
/usr/include/spawn.h
/usr/include/thread_db.h
/usr/include/xlocale.h

Therefore I propose this patch.

2006-01-07  Bruno Haible  <[EMAIL PROTECTED]>

* argp.h (__const): Remove macro. Use const instead.
* argp-fmtstream.h (__const): Likewise.
* glob_.h (__const): Remove macro.
* glob-libc.h: Use const instead of __const.

*** argp.h.bak  2005-07-04 13:16:19.0 +0200
--- argp.h  2006-01-07 18:33:51.0 +0100
***
*** 1,5 
  /* Hierarchial argument parsing, layered over getopt.
!Copyright (C) 1995-1999,2003,2004 Free Software Foundation, Inc.
 This file is part of the GNU C Library.
 Written by Miles Bader <[EMAIL PROTECTED]>.
  
--- 1,5 
  /* Hierarchial argument parsing, layered over getopt.
!Copyright (C) 1995-1999,2003-2006 Free Software Foundation, Inc.
 This file is part of the GNU C Library.
 Written by Miles Bader <[EMAIL PROTECTED]>.
  
***
*** 28,37 
  #define __need_error_t
  #include 
  
- #ifndef __const
- # define __const const
- #endif
- 
  #ifndef __THROW
  # define __THROW
  #endif
--- 28,33 
***
*** 82,88 
  {
/* The long option name.  For more than one name for the same option, you
   can use following options with the OPTION_ALIAS flag set.  */
!   __const char *name;
  
/* What key is returned for this option.  If > 0 and printable, then it's
   also accepted as a short option.  */
--- 78,84 
  {
/* The long option name.  For more than one name for the same option, you
   can use following options with the OPTION_ALIAS flag set.  */
!   const char *name;
  
/* What key is returned for this option.  If > 0 and printable, then it's
   also accepted as a short option.  */
***
*** 90,96 
  
/* If non-NULL, this is the name of the argument associated with this
   option, which is required unless the OPTION_ARG_OPTIONAL flag is set. */
!   __const char *arg;
  
/* OPTION_ flags.  */
int flags;
--- 86,92 
  
/* If non-NULL, this is the name of the argument associated with this
   option, which is required unless the OPTION_ARG_OPTIONAL flag is set. */
!   const char *arg;
  
/* OPTION_ flags.  */
int flags;
***
*** 99,105 
   will be printed outdented from the normal option column, making it
   useful as a group header (it will be the first thing printed in its
   group); in this usage, it's conventional to end the string with a `:'.  
*/
!   __const char *doc;
  
/* The group this option is in.  In a long help message, options are sorted
   alphabetically within each group, and the groups presented in the order
--- 95,101 
   will be printed outdented from the normal option column, making it
   useful as a group header (it will be the first thing printed in its
   group); in this usage, it's conventional to end the string with a `:'.  
*/
!   const char *doc;
  
/* The group this option is in.  In a long help message, options are sorted
   alphabetically within each group, and the groups presented in the order
***
*** 227,233 
  {
/* An array of argp_option structures, terminated by an entry with both
   NAME and KEY having a value of 0.  */
!   __const struct argp_option *options;
  
/* What to do with an option from this structure.  KEY is the key
   associated with the option, and ARG is any associated argument (NULL if
--- 223,229 
  {
/* An array of argp_option structures, terminated by an entry with both
   NAME and KEY having a value of 0.  */
!   const struct argp_option *options;
  
/* What to do with an option from this structure.  KEY is the key
   associated with the option, and ARG is any associated argument (NULL if
***
*** 243,254 
   contains newlines, the strings separated by them are considered
   alternative usage patterns, and printed on separate lines (lines after
   the first are prefix by `  or: ' instead of `Usage:').  */
!   __const char *args_doc;
  
/* If non-NULL, a string containing extra text to be printed before and
   after the options in a long help message (separated by a vertical tab
   `\v' character).  */
!   __const char *doc;
  
/* A vector of argp_children structures, terminated by a member with a 0
   argp field, pointing to child argps should be parsed with this one.  Any
--- 239,250 
   conta

Re: Separate csharpcomp.sh, and a license problem

[Simon Josefsson]

Bruno Haible <[EMAIL PROTECTED]> writes:

> Simon Josefsson wrote:
>> How would build-aux/ be substituted into $auxdir?  Should gnulib-tool
>> substitute 'build-aux/' in configure.ac:-statements to $auxdir?
>
> Yes, it should. I'll prepare a patch for doing this.

That would solve this problem.  I hope the substitution regexp doesn't
inadvertently modify something unintended, i.e. 'lib/' that isn't
meant to be the gnulib directory.  But I'm having a hard time coming
up with an example of when that would happen, so it is probably not a
problem.


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

Re: use of -fno-common on Darwin

[Peter O'Gorman]

Bruno Haible wrote:

Paul Eggert wrote:


"Peter O'Gorman" <[EMAIL PROTECTED]> writes:


getprogname(3), if it exists, can be used as well as other
alternatives (e.g. argv[0]).


Thanks, I wasn't aware of the BSD getprogname until now.



Me too.



How about this proposal?

* Change the progname module to use the BSD getprogname naming
 convention.  No sense reinventing the wheel.  That way, programs can
 simply use the system-defined functions on BSD.

* Rewrite the other gnulib code to use the new convention.

* Ask gnulib users to switch to the new convention.



Yes, that's the most sensible thing to do. If there are no objections,
I will change the 'progname' module accordingly.

[libtool list cut]

Solaris seems to have a getexecname, so between, getprogname, getexecname 
and program_invocation_short_name, BSD, solaris and glibc using OSes are 
covered. I'd suggest the following instead of Paul's proposal, as it allows 
the programmer to override the program name. Given that though, Paul's 
proposal is better than current.


static char * prog_name = NULL;

void
set_prog_name(char * name)
{
if (prog_name) free(prog_name);
prog_name = strdup(name);
}

char *
get_prog_name(void)
{
char * name;
if (prog_name)
name = prog_name;
else
{
#if defined(HAVE_GETPROGNAME)
#include 
name = getprogname();
#elif defined(HAVE_GETEXECNAME)
#include 
name = getexecname();
#elif defined(HAVE_PROGRAM_INVOCATION_SHORT_NAME)
#include 
name = program_invocation_short_name;
#else
name = "executable";
#endif
}
return name;
}


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

bug in strtok_r module

[Bruno Haible]

$ ./gnulib-tool --create-testdir --dir=testdir strtok_r
...
configure.ac:14: warning: gl_C_RESTRICT is m4_require'd but is not m4_defun'd
configure.ac:14: gl_C_RESTRICT is required by...
m4/strtok_r.m4:17: gl_PREREQ_STRTOK_R is expanded from...
m4/strtok_r.m4:12: gl_FUNC_STRTOK_R is expanded from...

The reason is that m4/strtok_r.m4 invokes gl_C_RESTRICT, but m4/restrict.m4 is
not part of this module or its dependencies.

Here is a fix. OK to commit?


2006-01-08  Bruno Haible  <[EMAIL PROTECTED]>

* modules/strtok_r: Depend on module restrict.

*** modules/strtok_r.bak2004-11-12 01:00:47.0 +0100
--- modules/strtok_r2006-01-08 16:30:45.0 +0100
***
*** 7,12 
--- 7,13 
  m4/strtok_r.m4
  
  Depends-on:
+ restrict
  
  configure.ac:
  gl_FUNC_STRTOK_R




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

bug in readutmp module

[Bruno Haible]

Jim,

"gnulib-tool --create-megatestdir --dir=/dev/shm/testdir --with-tests"
shows this:

configure.ac:20: warning: gl_FUNC_FREE is m4_require'd but is not m4_defun'd
configure.ac:20: gl_FUNC_FREE is required by...
m4/readutmp.m4:55: gl_READUTMP is expanded from...

The reason is that m4/readutmp.m4 invokes gl_FUNC_FREE, but m4/free.m4 is not
part of this module or its dependencies.

Here is a fix. OK to commit?


2006-01-08  Bruno Haible  <[EMAIL PROTECTED]>

* m4/readutmp.m4 (gl_READUTMP): Don't require gl_FUNC_FREE. Use a
module dependency instead.
* modules/readutmp: Depend on module free.

*** m4/readutmp.m4.bak  2005-05-02 13:27:38.0 +0200
--- m4/readutmp.m4  2006-01-08 15:30:53.0 +0100
***
*** 1,5 
! # readutmp.m4 serial 9
! dnl Copyright (C) 2002, 2003, 2004, 2005 Free Software Foundation, Inc.
  dnl This file is free software; the Free Software Foundation
  dnl gives unlimited permission to copy and/or distribute it,
  dnl with or without modifications, as long as this notice is preserved.
--- 1,5 
! # readutmp.m4 serial 10
! dnl Copyright (C) 2002, 2003, 2004, 2005, 2006 Free Software Foundation, Inc.
  dnl This file is free software; the Free Software Foundation
  dnl gives unlimited permission to copy and/or distribute it,
  dnl with or without modifications, as long as this notice is preserved.
***
*** 11,17 
  
dnl Prerequisites of lib/readutmp.h and lib/readutmp.c.
AC_REQUIRE([AC_C_INLINE])
-   AC_REQUIRE([gl_FUNC_FREE])
AC_CHECK_HEADERS_ONCE(utmp.h utmpx.h)
AC_CHECK_FUNCS_ONCE(utmpname utmpxname)
AC_CHECK_DECLS(getutent,,,[
--- 11,16 
*** modules/readutmp.bak2005-05-09 16:27:12.0 +0200
--- modules/readutmp2006-01-08 15:31:09.0 +0100
***
*** 8,13 
--- 8,14 
  
  Depends-on:
  xalloc
+ free
  stdbool
  
  configure.ac:




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

Re: sys/socket.h on mingw32 vs socklen (resend)

[Simon Josefsson]

Bruno Haible <[EMAIL PROTECTED]> writes:

> Simon Josefsson wrote:
>> >> + rmdir sys
>> >
>> > Remove the directory only when it exists and is empty. (Some systems
>> > create files in your directories without being asked for, e.g. .DS_Store
>> > on MacOS X.)
>>
>> How do I test for that in a portable way?
>
> Let rmdir do the test, and ignore a possible error:
>
>   -rmdir sys 2>/dev/null

Of course.  Added.

>> Applications that need socklen_t should probably depend on
>> the sys/socket.h module.  Perhaps the socklen_t module should depend
>> on the sys_socket module?
>
> I don't think so: Applications that use  but not 
> are also supposed to be able to use socklen_t. See
> http://www.opengroup.org/onlinepubs/009695399/basedefs/netdb.h.html

Right.

>> +AC_DEFUN([gl_HEADER_SYS_SOCKET],
>> +[
>> +  AC_CHECK_HEADERS_ONCE([sys/socket.h])
>> +  if test $ac_cv_header_sys_socket_h = yes; then
>> +SYS_SOCKET_H=''
>> +  else
>> +AC_CHECK_HEADERS_ONCE([winsock2.h])
>
> Here a test for ws2tcpip.h is missing.

Added.

>> --- /dev/null1 Jan 1970 00:00:00 -
>> +++ modules/sys_socket   9 Jan 2006 16:24:40 -
>> @@ -0,0 +1,36 @@
>> +Description:
>> +A  for systems lacking it.
>> +(Currently only useful for mingw32, it will simply include winsock2.h.)
>
> The second line doesn't belong here, IMO, since it describes the
> implementation of the module, which can change over time if we encounter
> more bad systems.

Removed.

> Otherwise it looks fine, please commit!

I installed the patch below.

Thanks!

Index: lib/socket_.h
===
RCS file: lib/socket_.h
diff -N lib/socket_.h
--- /dev/null   1 Jan 1970 00:00:00 -
+++ lib/socket_.h   10 Jan 2006 14:28:10 -
@@ -0,0 +1,37 @@
+/* Provide a sys/socket header file for systems lacking it (read: mingw32).
+   Copyright (C) 2005, 2006 Free Software Foundation, Inc.
+   Written by Simon Josefsson.
+
+   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 2, 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, write to the Free Software Foundation,
+   Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.  */
+
+#ifndef _SYS_SOCKET_H
+#define _SYS_SOCKET_H
+
+/* This file is supposed to be used on platforms that lack
+   sys/socket.h.  It is intended to provide definitions and prototypes
+   needed by an application.
+
+   Currently only mingw32 is supported, which has the header files
+   winsock2.h and ws2tcpip.h that declare the sys/socket.h definitions
+   we need. */
+
+#if HAVE_WINSOCK2_H
+# include 
+#endif
+#if HAVE_WS2TCPIP_H
+# include 
+#endif
+
+#endif /* _SYS_SOCKET_H */
Index: lib/ChangeLog
===
RCS file: /sources/gnulib/gnulib/lib/ChangeLog,v
retrieving revision 1.1069
diff -u -p -r1.1069 ChangeLog
--- lib/ChangeLog   10 Jan 2006 13:52:11 -  1.1069
+++ lib/ChangeLog   10 Jan 2006 14:28:12 -
@@ -1,3 +1,7 @@
+2006-01-10  Simon Josefsson  <[EMAIL PROTECTED]>
+
+   * socket_.h: New file.
+
 2006-01-10  Bruno Haible  <[EMAIL PROTECTED]>
 
* localcharset.c: Update from GNU gettext.
Index: m4/sys_socket_h.m4
===
RCS file: m4/sys_socket_h.m4
diff -N m4/sys_socket_h.m4
--- /dev/null   1 Jan 1970 00:00:00 -
+++ m4/sys_socket_h.m4  10 Jan 2006 14:28:12 -
@@ -0,0 +1,19 @@
+# sys_socket_h.m4 serial 1
+dnl Copyright (C) 2005, 2006 Free Software Foundation, Inc.
+dnl This file is free software; the Free Software Foundation
+dnl gives unlimited permission to copy and/or distribute it,
+dnl with or without modifications, as long as this notice is preserved.
+
+dnl From Simon Josefsson.
+
+AC_DEFUN([gl_HEADER_SYS_SOCKET],
+[
+  AC_CHECK_HEADERS_ONCE([sys/socket.h])
+  if test $ac_cv_header_sys_socket_h = yes; then
+SYS_SOCKET_H=''
+  else
+AC_CHECK_HEADERS_ONCE([winsock2.h ws2tcpip.h])
+SYS_SOCKET_H='sys/socket.h'
+  fi
+  AC_SUBST(SYS_SOCKET_H)
+])
Index: m4/ChangeLog
===
RCS file: /sources/gnulib/gnulib/m4/ChangeLog,v
retrieving revision 1.767
diff -u -p -r1.767 ChangeLog
--- m4/ChangeLog10 Jan 2006 13:57:21 -  1.767
+++ m4/ChangeLog10 Jan 2006 14:28:13 -
@@ -1,3 +1,7 @@
+2006-01-10  Simon Josefsson  <[EMAIL PROTECTED]>
+
+   * sys_socket_h.m4: New file.
+
 2006-01-10  Bruno Haible  <[EMAIL PROTECTED]>
 
* l

Re: getprogname

[Bruno Haible]

Peter O'Gorman wrote:
> Solaris seems to have a getexecname

Interesting. So this provides a fallback, like on glibc systems, for the
case when setprogname(argv[0]) has not been called.

> I'd suggest the following instead of Paul's proposal, as it allows
> the programmer to override the program name.

Well, Paul's proposal to use 'get/setprogname' also allows the
programmer to override the program name.

> static char * prog_name = NULL;
>
> void
> set_prog_name(char * name)
> {
>   if (prog_name) free(prog_name);
>   prog_name = strdup(name);
> }
>
> char *
> get_prog_name(void)
> {
>   char * name;
>   if (prog_name)
>   name = prog_name;
>   else
>   {
> #if defined(HAVE_GETPROGNAME)
> #include 
>   name = getprogname();
> #elif defined(HAVE_GETEXECNAME)
> #include 
>   name = getexecname();
> #elif defined(HAVE_PROGRAM_INVOCATION_SHORT_NAME)
> #include 
>   name = program_invocation_short_name;
> #else
>   name = "executable";
> #endif
>   }
>   return name;
> }

Well, my intention is basically this:

#if !(HAVE_GETPROGNAME && HAVE_SETPROGNAME) /* nothing to do on FreeBSD, NetBSD 
*/

static const char * progname = NULL;

void
setprogname(const char *arg)
{
  progname = arg;
}

const char *
getprogname()
{
  if (progname != NULL)
/* actually not only basename, but also remove leading "-" and ".lt-" */
return basename (progname);
  else
{
  #if HAVE_PROGRAM_INVOCATION_SHORT_NAME /* glibc */
return program_invocation_short_name;
  #elif HAVE_GETEXECNAME /* Solaris */
return basename (getexecname ());
  #else
return NULL;
  #endif
}
}

#endif

Bruno



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

Re: bug in 'iconvme' module

[Simon Josefsson]

Bruno Haible <[EMAIL PROTECTED]> writes:

> Simon,
>
> On MacOS X with GNU libiconv module, the iconvme module exhibits a build
> failure:
>
> Making all in lib
> make  all-am
> gcc -DHAVE_CONFIG_H -I. -I../../../megatestdir/iconvme/lib -I.. -g -O2 -c 
> ../../../megatestdir/iconvme/lib/iconvme.c
> ../../../megatestdir/iconvme/lib/iconvme.c: In function `iconv_alloc':
> ../../../megatestdir/iconvme/lib/iconvme.c:134: warning: passing arg 2 of 
> `libiconv' from incompatible pointer type
> rm -f libgnu.a
> ar cru libgnu.a iconvme.o -liconv
> ar: -liconv: No such file or directory
> make[4]: *** [libgnu.a] Error 1
> make[4]: Target `all-am' not remade because of errors.
> make[3]: *** [all] Error 2
>
> IMO you need to add $(LTLIBICONV) to lib_LDFLAGS, not lib_LIBADD.
> And also, use $(LIBICONV) instead of $(LTLIBICONV) when libtool is not used.
> That's why you introduced GL_COND_LIBTOOL conditional, no?

I think iconvme was written before the recent libtool changes.  If you
make those changes, does it work?  If so, please feel free to commit
them.  If they cause me any problem (presumably in libidn), I'll
report it later on.

Thanks,
Simon


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

Re: bug in readutmp module

[Bruno Haible]

Jim Meyering wrote:
> However, I'm reluctant to remove the AC_REQUIRE, since
> that would make the code+.m4 combination depend silently on
> having a particular implementation of free.

Yes, I understand. By looking at the source code, it's not immediately
clear which free() variant is meant.

> Thinking about it some more, it seems backwards to move the
> dependency information from the .m4 file to the module file.
> I think of the .m4 file as recording dependencies inherent in the
> corresponding source files.

The benefit of the module dependency is that it is immune against changes
in the interface of the other module. For example, when you rename
jm_SSIZE_T to gl_TYPE_SSIZE_T, or add other lines in the "configure.ac"
section of the module, the higher-level module doesn't need to be changed.

The drawback is obviously that if you have several source files gathered
in a module, you lose track which file needs what, if you don't have a
more fine-grained way of tracking the dependency. You could choose to
track them through comments. Or in the .m4 file. Either is fine with me.

> How about if we leave the now-redundant
> AC_REQUIRE in place for now?

Done. I committed only the other part.

Bruno



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

Re: bug in readutmp module

[Jim Meyering]

Bruno Haible <[EMAIL PROTECTED]> wrote:
> The reason is that m4/readutmp.m4 invokes gl_FUNC_FREE, but m4/free.m4 is not
> part of this module or its dependencies.
>
> Here is a fix. OK to commit?

Hi Bruno!

Thanks for working on this.

Adding the module dependency is fine.

However, I'm reluctant to remove the AC_REQUIRE, since
that would make the code+.m4 combination depend silently on
having a particular implementation of free.  I know that
there are many other instances where dependencies have moved
from .m4 file to the corresponding modules/ file, and
everyone should use gnulib-tool, but ...

Thinking about it some more, it seems backwards to move the
dependency information from the .m4 file to the module file.
I think of the .m4 file as recording dependencies inherent in the
corresponding source files.  How about if we leave the now-redundant
AC_REQUIRE in place for now?  Maybe someone will make gnulib-tool
automatically detect such dependencies.

> 2006-01-08  Bruno Haible  <[EMAIL PROTECTED]>
>
>   * m4/readutmp.m4 (gl_READUTMP): Don't require gl_FUNC_FREE. Use a
>   module dependency instead.
>   * modules/readutmp: Depend on module free.


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

Re: error compiling regex gnulib module with pgcc compiler

[Paul Eggert]

Ralf Wildenhues <[EMAIL PROTECTED]> writes:

>> Thanks for checking that.  Can you please run the following
>> program on that platform and send us the output?  If it outputs
>> "preprocessor thinks BITSET_WORD_BITS = 64", then we have an
>> obvious fix to regex_internal.h.  Thanks.
>
> Yes

OK, thanks, I installed the following patch into both gnulib and
coreutils.  A pgcc maintainer wrote me that this should be fixed when
version 6.1-2 comes out, so I put that into the comment.

2006-01-10  Paul Eggert  <[EMAIL PROTECTED]>

* regex_internal.h (BITSET_WORD_BITS):
Work around a bug in 64-bit PGC (before version 6.1-2), where the
preprocessor mishandles large unsigned values as if they were signed.
Problem reported by Claudio Fontana in
.

Index: regex_internal.h
===
RCS file: /cvsroot/gnulib/gnulib/lib/regex_internal.h,v
retrieving revision 1.19
retrieving revision 1.20
diff -p -u -r1.19 -r1.20
--- regex_internal.h25 Sep 2005 04:20:16 -  1.19
+++ regex_internal.h10 Jan 2006 20:14:43 -  1.20
@@ -1,5 +1,5 @@
 /* Extended regular expression matching and search library.
-   Copyright (C) 2002, 2003, 2004, 2005 Free Software Foundation, Inc.
+   Copyright (C) 2002, 2003, 2004, 2005, 2006 Free Software Foundation, Inc.
This file is part of the GNU C Library.
Contributed by Isamu Hasegawa <[EMAIL PROTECTED]>.
 
@@ -182,6 +182,10 @@ typedef unsigned long int bitset_word;
 # if BITSET_WORD_BITS <= SBC_MAX
 #  error "Invalid SBC_MAX"
 # endif
+ #elif BITSET_WORD_MAX == (0x + 2) * 0x
+/* Work around a bug in 64-bit PGC (before version 6.1-2), where the
+   preprocessor mishandles large unsigned values as if they were signed.  */
+# define BITSET_WORD_BITS 64
 #else
 # error "Add case for new bitset_word size"
 #endif


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

Re: getprogname

[Paul Eggert]

Bruno Haible <[EMAIL PROTECTED]> writes:

> Well, my intention is basically this:

A few comments.

This isn't as compatible as possible with BSD, as BSD setprogname
ignores its argument when the true program name is available from
the operating system.

LibGW32C-0.3 has getexecname (see
), so
that function is not unique to Solaris.

I just looked it up, and on Solaris, getexecname might fail and return
NULL, on programs that are linked statically.

Surely you meant base_name rather than basename?

How about something like this instead?


#if !HAVE_GETEXECNAME
# define getexecname() NULL
#endif

#if !HAVE_GETPROGNAME

static const char *progname;

void
setprogname (const char *arg)
{
  progname = arg;
}

const char *
getprogname ()
{
#if HAVE_PROGRAM_INVOCATION_SHORT_NAME /* glibc */
  return program_invocation_short_name;
#else
  const char *p = getexecname ();
  return base_name (p ? p : progname);
#endif
}

#endif


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

Re: getprogname

[Bruno Haible]

Paul Eggert wrote:
> This isn't as compatible as possible with BSD, as BSD setprogname
> ignores its argument when the true program name is available from
> the operating system.

Huh? My reading of the sources of FreeBSD

  
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/gen/getprogname.c?rev=1.4&content-type=text/x-cvsweb-markup
  
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/gen/setprogname.c?rev=1.8&content-type=text/x-cvsweb-markup

and NetBSD

  
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/gen/getprogname.c?rev=1.3&content-type=text/x-cvsweb-markup
  
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/gen/setprogname.c?rev=1.3&content-type=text/x-cvsweb-markup

is just the opposite: Whatever may the initial value of __progname be,
it is erased when setprogname is called.

Which is also reasonable: you want to allow an application to override
system behaviour, not the other way around.

> LibGW32C-0.3 has getexecname (see
> ), so
> that function is not unique to Solaris.

And LibGW32C-0.4 (see http://gnuwin32.sourceforge.net/packages/libgw32c.htm)
has apparently renamed this function to getprogname(). While _not_ providing
a setprogname().

> Surely you meant base_name rather than basename?

What I presented was only a sketch. Let's discuss details when I show
the real code.

> How about something like this instead?

It's missing the removal of the dirname, of "-" and of "lt-". Also,
it lacks a setprogname() function if the system provides getprogname()
but not setprogname().

Bruno



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

Re: problem with multibyte constants under Mac OS X 10.3.9 in lib/fnmatch_loop.c

[Paul Eggert]

Claudio Fontana <[EMAIL PROTECTED]> writes:

> gcc3 -DHAVE_CONFIG_H -I. -I. -I..  
> -I/usr/local/include 
> -I/System/Library/Frameworks/CoreFoundation.framework/Headers
>  -g -O2 -c fnmatch.c
> fnmatch_loop.c:42: illegal statement, missing `)' after `L'

Wow, that looks like a GCC bug.  Which version of GCC is it, exactly?
What does the command "gcc3 --version" output?

Does the following patch work around the bug?

2006-01-10  Paul Eggert  <[EMAIL PROTECTED]>

* lib/fnmatch.c (L_): Renamed from L, to work around a bug in
Mac OS X 10.3.9 with GCC 3 reported by Claudio Fontana in
.
All uses changed.

Index: lib/fnmatch.c
===
RCS file: /cvsroot/gnulib/gnulib/lib/fnmatch.c,v
retrieving revision 1.32
diff -p -u -r1.32 fnmatch.c
--- lib/fnmatch.c   19 Sep 2005 17:28:14 -  1.32
+++ lib/fnmatch.c   10 Jan 2006 22:23:20 -
@@ -180,7 +180,7 @@ static int posixly_correct;
 # define FCT   internal_fnmatch
 # define EXT   ext_match
 # define END   end_pattern
-# define L(CS) CS
+# define L_(CS)CS
 # ifdef _LIBC
 #  define BTOWC(C) __btowc (C)
 # else
@@ -210,7 +210,7 @@ static int posixly_correct;
 #  define FCT  internal_fnwmatch
 #  define EXT  ext_wmatch
 #  define END  end_wpattern
-#  define L(CS)L##CS
+#  define L_(CS)   L##CS
 #  define BTOWC(C) (C)
 #  ifdef _LIBC
 #   define STRLEN(S) __wcslen (S)
Index: lib/fnmatch_loop.c
===
RCS file: /cvsroot/gnulib/gnulib/lib/fnmatch_loop.c,v
retrieving revision 1.10
diff -p -u -r1.10 fnmatch_loop.c
--- lib/fnmatch_loop.c  2 Jun 2005 20:41:05 -   1.10
+++ lib/fnmatch_loop.c  10 Jan 2006 22:23:20 -
@@ -39,14 +39,14 @@ FCT (const CHAR *pattern, const CHAR *st
 # endif
 #endif
 
-  while ((c = *p++) != L('\0'))
+  while ((c = *p++) != L_('\0'))
 {
   bool new_no_leading_period = false;
   c = FOLD (c);
 
   switch (c)
{
-   case L('?'):
+   case L_('?'):
  if (__builtin_expect (flags & FNM_EXTMATCH, 0) && *p == '(')
{
  int res;
@@ -59,17 +59,17 @@ FCT (const CHAR *pattern, const CHAR *st
 
  if (n == string_end)
return FNM_NOMATCH;
- else if (*n == L('/') && (flags & FNM_FILE_NAME))
+ else if (*n == L_('/') && (flags & FNM_FILE_NAME))
return FNM_NOMATCH;
- else if (*n == L('.') && no_leading_period)
+ else if (*n == L_('.') && no_leading_period)
return FNM_NOMATCH;
  break;
 
-   case L('\\'):
+   case L_('\\'):
  if (!(flags & FNM_NOESCAPE))
{
  c = *p++;
- if (c == L('\0'))
+ if (c == L_('\0'))
/* Trailing \ loses.  */
return FNM_NOMATCH;
  c = FOLD (c);
@@ -78,7 +78,7 @@ FCT (const CHAR *pattern, const CHAR *st
return FNM_NOMATCH;
  break;
 
-   case L('*'):
+   case L_('*'):
  if (__builtin_expect (flags & FNM_EXTMATCH, 0) && *p == '(')
{
  int res;
@@ -89,12 +89,12 @@ FCT (const CHAR *pattern, const CHAR *st
return res;
}
 
- if (n != string_end && *n == L('.') && no_leading_period)
+ if (n != string_end && *n == L_('.') && no_leading_period)
return FNM_NOMATCH;
 
- for (c = *p++; c == L('?') || c == L('*'); c = *p++)
+ for (c = *p++; c == L_('?') || c == L_('*'); c = *p++)
{
- if (*p == L('(') && (flags & FNM_EXTMATCH) != 0)
+ if (*p == L_('(') && (flags & FNM_EXTMATCH) != 0)
{
  const CHAR *endp = END (p);
  if (endp != p)
@@ -105,13 +105,13 @@ FCT (const CHAR *pattern, const CHAR *st
}
}
 
- if (c == L('?'))
+ if (c == L_('?'))
{
  /* A ? needs to match one character.  */
  if (n == string_end)
/* There isn't another character; no match.  */
return FNM_NOMATCH;
- else if (*n == L('/')
+ else if (*n == L_('/')
   && __builtin_expect (flags & FNM_FILE_NAME, 0))
/* A slash does not match a wildcard under
   FNM_FILE_NAME.  */
@@ -124,7 +124,7 @@ FCT (const CHAR *pattern, const CHAR *st
}
}
 
- if (c == L('\0'))
+ if (c == L_('\0'))
/* The wildcard(s) is/are the last element of the pattern.
   If the name is a file name and contains another slash
   this means it cannot match, unless the FNM_LEADING_DIR
@@ -138,7 +138,7 @@ FCT (const CHAR *pattern, const CHAR *st
result = 0;
   

Re: [bug-gnulib] no module for progreloc

[Bruno Haible]

Werner LEMBERG wrote:
> There isn't a file `modules/progreloc' which looks like a bug to me
> since it depends on progname.

Yes, the "relocatable" stuff does not yet fit into a gnulib module.
The installation instructions ([1]) require some modification to
every Makefile.am and to every installable executable or shell script.
I believe it will need a bit of automake support in order to work as
transparently as other features.

Bruno

[1] http://lists.gnu.org/archive/html/bug-gnulib/2003-03/msg00020.html



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

no module for progreloc

[Werner LEMBERG]

There isn't a file `modules/progreloc' which looks like a bug to me
since it depends on progname.


Werner


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

Re: __const

[Paul Eggert]

Bruno Haible <[EMAIL PROTECTED]> writes:

> 2006-01-07  Bruno Haible  <[EMAIL PROTECTED]>
>
>   * argp.h (__const): Remove macro. Use const instead.
>   * argp-fmtstream.h (__const): Likewise.
>   * glob_.h (__const): Remove macro.
>   * glob-libc.h: Use const instead of __const.

Thanks for cleaning that up.  I installed it.


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

Re: use of -fno-common on Darwin

[James Youngman]

On Tue, Jan 10, 2006 at 11:07:20PM +0900, Peter O'Gorman wrote:

> char *
> get_prog_name(void)
> {
>   char * name;
>   if (prog_name)
>   name = prog_name;
>   else
>   {
> #if defined(HAVE_GETPROGNAME)
> #include 
>   name = getprogname();
> #elif defined(HAVE_GETEXECNAME)
> #include 
>   name = getexecname();
> #elif defined(HAVE_PROGRAM_INVOCATION_SHORT_NAME)
> #include 
>   name = program_invocation_short_name;
> #else
>   name = "executable";
> #endif
>   }
>   return name;
> }

If we adopted this code, application authors would still be obliged to
call set_program_name() since there would still be platforms where the 

>   name = "executable";

clause is executed.  However, this clause will only be exercised on
some systems, so having a good default here simply helps to mask bugs.
This is especially unfortunate where developers have a machine which
can figure out the executable name unaided, but end-users don't.

James.



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

Re: bug in strtok_r module

[Paul Eggert]

Bruno Haible <[EMAIL PROTECTED]> writes:

> 2006-01-08  Bruno Haible  <[EMAIL PROTECTED]>
>
> * modules/strtok_r: Depend on module restrict.

> 2006-01-08  Bruno Haible  <[EMAIL PROTECTED]>
>
>   * m4/readutmp.m4 (gl_READUTMP): Don't require gl_FUNC_FREE. Use a
>   module dependency instead.
>   * modules/readutmp: Depend on module free.

Thanks for those two patches.  I installed them.  I also added myself
to the modules/readutmp maintainer list, since I've been doing so many
of the changes to that module recently.


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

Re: getprogname

[Paul Eggert]

Bruno Haible <[EMAIL PROTECTED]> writes:

> Paul Eggert wrote:
>> This isn't as compatible as possible with BSD, as BSD setprogname
>> ignores its argument when the true program name is available from
>> the operating system.
>
> Huh? My reading of the sources of FreeBSD and NetBSD is just the
> opposite: Whatever may the initial value of __progname be, it is
> erased when setprogname is called.

Hmm, no, actually they differ.  NetBSD agrees with me and FreeBSD with
you.  (See the REALLY_SET_PROGNAME macro in the NetBSD
implementation.)  Ouch.

I was assuming NetBSD, since it introduced the feature.  Also,

says "in NetBSD, calling setprogname() from main() has no effect."

> Which is also reasonable: you want to allow an application to override
> system behaviour, not the other way around.

Since there's conflicting practice we might as well do the reasonable
thing, yes.  (But I wonder why NetBSD went to the trouble of doing it
that way?)


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

Re: bug in readutmp module

[Paul Eggert]

Bruno Haible <[EMAIL PROTECTED]> writes:

> Jim Meyering wrote:
>> How about if we leave the now-redundant
>> AC_REQUIRE in place for now?
>
> Done. I committed only the other part.

Thanks.  I mistakenly committed the whole change earlier, but undid
the mistake just now.


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