wcwidth module license change

[Yoann Vandoorselaere]

Hi,

The wcwidth module license has changed from LGPL to GPL. However,
several LGPL modules still directly depend on it (mbchar, mbswidth).
Could the wcwidth module license be reverted to LGPL ?

Thanks,

-- 
Yoann Vandoorselaere | Responsable R&D / CTO | PreludeIDS Technologies
Tel: +33 (0)8 70 70 21 58  Fax: +33(0)4 78 42 21 58
http://www.prelude-ids.com

Re: c-bs-a

[Derek R. Price]

Paul Eggert wrote:
> "Derek R. Price" <[EMAIL PROTECTED]> writes:
> 
>> Autoconf 2.60 lists AC_C_BACKSLASH_A as obsolescent because the problem
>> it fixes is so ancient.  Would it be okay to remove the module?
> 
> Yes, that's fine with me, since '\a' is part of C89.
> Thanks.

Done.

Regards,

Derek
-- 
Derek R. Price
CVS Solutions Architect
Get CVS support at Ximbiot !
v: +1 248.835.1260
f: +1 248.835.1263

Re: memcmp module

[Derek R. Price]

Paul Eggert wrote:

> PS.  By the way, when you remove m4/c-bs-a.m4, please don't forget to
> update MODULES.html.sh accordingly.

Missed it the first time, but I've now installed this change.  Thanks.

Regards,

Derek
-- 
Derek R. Price
CVS Solutions Architect
Get CVS support at Ximbiot !
v: +1 248.835.1260
f: +1 248.835.1263

Re: wcwidth module license change

[Bruno Haible]

Yoann Vandoorselaere wrote:
> The wcwidth module license has changed from LGPL to GPL. However,
> several LGPL modules still directly depend on it (mbchar, mbswidth).

You're right regarding 'mbchar'.

> Could the wcwidth module license be reverted to LGPL ?

Sure. Done.

Bruno

Re: memcmp module

[Jim Meyering]

Paul Eggert <[EMAIL PROTECTED]> wrote:
> "Derek R. Price" <[EMAIL PROTECTED]> writes:
>
>> The memcmp module is only useful with AC_FUNC_MEMCMP, which Autoconf
>> 2.60 declares obsolescent.  No other GNULIB modules reference this
>> module, so could it be removed?
>
> I think I'd rather keep this around a leettle while longer, since
> it depends on C libraries, not the C compilers themselves, and on
> a freestanding C89 system the libraries might be dodgy.
>
> If we want to remove memcmp, we should also look at the list of C89
> modules in MODULES.html.sh (assert, dummy, exit, atexit, etc.) and
> perhaps remove them as well.  Some of them we'd have to keep (e.g.,
> mktime, which works around many common bugs even in C99 hosts) but
> others could go I suppose.
>
> PS.  By the way, when you remove m4/c-bs-a.m4, please don't forget to
> update MODULES.html.sh accordingly.

How about leaving it in for a while longer, but adding some sort of
assertion that will trigger if ever configure detects it's needed.

Here's what I did recently for coreutils:
Note that it does provide a way to continue on with the build.

2006-06-18  Jim Meyering  <[EMAIL PROTECTED]>

* ftruncate.m4 (gl_FUNC_FTRUNCATE): If ftruncate is missing, make
configure fail, and request a bug report to inform us about it.
Add a comment that, barring reports to the contrary, in 2007 we'll
assume ftruncate is universally available.

Index: m4/ftruncate.m4
===
RCS file: /fetish/cu/m4/ftruncate.m4,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -p -u -r1.9 -r1.10
--- m4/ftruncate.m4 22 Sep 2005 06:05:39 -  1.9
+++ m4/ftruncate.m4 18 Jun 2006 14:00:35 -  1.10
@@ -1,17 +1,29 @@
-#serial 8
+#serial 9
 
 # See if we need to emulate a missing ftruncate function using fcntl or chsize.
 
-# Copyright (C) 2000, 2001, 2003, 2004, 2005 Free Software Foundation, Inc.
+# Copyright (C) 2000, 2001, 2003-2006 Free Software Foundation, Inc.
 # This file is free software; the Free Software Foundation
 # gives unlimited permission to copy and/or distribute it,
 # with or without modifications, as long as this notice is preserved.
 
+# FIXME: remove this macro, along with all uses of HAVE_FTRUNCATE in 2007,
+# if the check below provokes no reports.
+
 AC_DEFUN([gl_FUNC_FTRUNCATE],
 [
   AC_REPLACE_FUNCS(ftruncate)
   if test $ac_cv_func_ftruncate = no; then
 gl_PREREQ_FTRUNCATE
+# If someone lacks ftruncate, make configure fail, and request
+# a bug report to inform us about it.
+if test x"$SKIP_FTRUNCATE_CHECK" != xyes; then
+  AC_MSG_FAILURE([Your system lacks the ftruncate function.
+ Please report this, along with the output of "uname -a", to the
+ bug-coreutils@gnu.org mailing list.  To continue past this point,
+ rerun configure with SKIP_FTRUNCATE_CHECK=yes set in the environment.
+ E.g., env SKIP_FTRUNCATE_CHECK=yes ./configure])
+fi
   fi
 ])
 

Re: [bug-gnulib] m4/isc-posix.m4

[Bruno Haible]

Derek R. Price wrote:
> I found this note in m4/isc-posix.m4:
> 
> # This file is not needed with autoconf-2.53 and newer.  Remove it in 2005.
> 
> The Autoconf 2.60 also marks AC_ISC_POSIX as obsolescent.

I will remove it in gettext-0.15.1. It will still be present in
gettext-0.15.

Bruno

Re: [bug-gnulib] AC_C_CONST

[Bruno Haible]

Derek R. Price wrote:
>   * m4/gettext.m4: Remove references to obsolescent AC_C_CONST.

I'll do this in gettext-0.15.1.

Bruno

Re: [bug-gnulib] Re: AC_FUNC_STRFTIME

[Bruno Haible]

Jim Meyering wrote:
> FYI, in spite of the fact that the module file lists
> "glibc" as the maintainer, we broke sync last year with
> my FPRINTFTIME changes.

Please feel free to update module description, for example like this:

--- modules/strftime4 Jul 2005 04:40:46 -   1.14
+++ modules/strftime29 Jun 2006 12:32:57 -
@@ -24,4 +24,4 @@
 LGPL
 
 Maintainer:
-glibc
+Jim Meyering, glibc

inet_ntop module proposed patch

[Bruno Haible]

Hi Yoann and Simon,

I propose to use #if HAVE_... instead of #ifdef HAVE_..., as customary in
gnulib (with the exception of HAVE_CONFIG_H).

diff -r -c3 --exclude=CVS gnulib-20060614-modified/lib/inet_ntop.h 
gnulib-20060628-modified/lib/inet_ntop.h
*** gnulib-20060614-modified/lib/inet_ntop.h2006-01-23 15:52:00.0 
+0100
--- gnulib-20060628-modified/lib/inet_ntop.h2006-06-29 00:15:15.0 
+0200
***
*** 17,23 
  
  #include 
  #include 
! #ifdef HAVE_ARPA_INET_H
  # include 
  #endif
  
--- 17,23 
  
  #include 
  #include 
! #if HAVE_ARPA_INET_H
  # include 
  #endif
  

Re: tempname.c vs. mingw

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Paul Eggert on 6/28/2006 10:32 AM:
> 
> I'd rather not do that.  Surely there's a less-intrusive way to fix
> this problem on nonstandard platforms like that.  You can use your own
>  replacement, for example.
> 

Here's my proposal for a  replacement, tested on native cygwin
and cross-compiling to mingw; with it, the mkstemp module compiles on
mingw.  Any feedback before I install this?

ChangeLog:
2006-06-29  Eric Blake  <[EMAIL PROTECTED]>

* MODULES.html.sh: Add sys_stat.
* modules/sys_stat: New module.
* modules/mkstemp (Depends-on): Add sys_stat.

doc/ChangeLog:
2006-06-28  Eric Blake  <[EMAIL PROTECTED]>

* functions.texi (Function Portability): Document missing lstat on
mingw.

lib/ChangeLog:
2006-06-29  Eric Blake  <[EMAIL PROTECTED]>

* stat_.h: New file.

m4/ChangeLog:
2006-06-29  Eric Blake  <[EMAIL PROTECTED]>

* sys_stat_h.m4 (gl_HEADER_SYS_STAT_H): New file.

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

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

iD8DBQFEo8nP84KuGfSFAYARAso7AJ9nTtFK77tMvwpuCCuygMGGBbuyewCgyMvu
3BRL4eoHE8bkKGAfmrVzWP8=
=+KBv
-END PGP SIGNATURE-
Index: MODULES.html.sh
===
RCS file: /sources/gnulib/gnulib/MODULES.html.sh,v
retrieving revision 1.119
diff -u -p -r1.119 MODULES.html.sh
--- MODULES.html.sh 29 Jun 2006 10:59:42 -  1.119
+++ MODULES.html.sh 29 Jun 2006 12:13:12 -
@@ -1808,6 +1808,7 @@ func_all_modules ()
   func_module rmdir
   func_module ssize_t
   func_module strtok_r
+  func_module sys_stat
   func_module unistd
   func_module utime
   func_module wcwidth
Index: doc/functions.texi
===
RCS file: /sources/gnulib/gnulib/doc/functions.texi,v
retrieving revision 1.3
diff -u -p -r1.3 functions.texi
--- doc/functions.texi  22 May 2006 18:52:10 -  1.3
+++ doc/functions.texi  29 Jun 2006 12:13:12 -
@@ -366,6 +366,9 @@ On platforms where @code{off_t} is a 32-
 correctly report the size of files or block devices larger than 2 GB.  The fix
 is to use the @code{AC_SYS_LARGEFILE} macro.
 
+On Windows systems (excluding Cygwin), symlinks are not supported, so
[EMAIL PROTECTED] does not exist.  Just define lstat to use stat.
+
 @item mbrtowc
 @itemx mbsrtowcs
 @itemx mbstowcs
Index: lib/stat_.h
===
RCS file: lib/stat_.h
diff -N lib/stat_.h
--- /dev/null   1 Jan 1970 00:00:00 -
+++ lib/stat_.h 29 Jun 2006 12:13:17 -
@@ -0,0 +1,43 @@
+/* Provide a complete sys/stat header file.
+   Copyright (C) 2006 Free Software Foundation, Inc.
+   Written by Eric Blake.
+
+   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 _gl_SYS_STAT_H
+#define _gl_SYS_STAT_H
+
+/* This file is supposed to be used on platforms where  is
+   incomplete.  It is intended to provide definitions and prototypes
+   needed by an application.  Start with what the system provides.  */
+#include @FULL_PATH_SYS_STAT_H@
+
+/* mingw does not support symlinks, therefore it does not have lstat.  But
+   without links, stat does just fine.  */
+#if ! HAVE_FUNC_LSTAT
+# define lstat stat
+#endif
+
+/* mingw's _mkdir() function has 1 argument, but we pass 2 arguments.
+   Therefore we have to disable the argument count checking.  Additionally,
+   it only declares _mkdir in the nonstandard io.h.  */
+#if ! HAVE_DECL_MKDIR
+# if HAVE_IO_H
+#  include 
+# endif
+# define mkdir ((int (*)()) _mkdir)
+#endif
+
+#endif /* _gl_SYS_STAT_H */
Index: m4/sys_stat_h.m4
===
RCS file: m4/sys_stat_h.m4
diff -N m4/sys_stat_h.m4
--- /dev/null   1 Jan 1970 00:00:00 -
+++ m4/sys_stat_h.m429 Jun 2006 12:13:17 -
@@ -0,0 +1,30 @@
+# sys_stat_h.m4 serial 1   -*- Autoconf -*-
+dnl Copyright (C) 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 modificati

inet_pton documentation

[Bruno Haible]

Hi Simon,

Can we add some documentation here? I don't find that the comment in
the implementation is clear enough.

diff -r -c3 --exclude=CVS gnulib-20060614-modified/lib/inet_pton.h 
gnulib-20060628-modified/lib/inet_pton.h
*** gnulib-20060614-modified/lib/inet_pton.h2006-06-29 01:30:47.0 
+0200
--- gnulib-20060628-modified/lib/inet_pton.h2006-06-29 00:32:23.0 
+0200
***
*** 21,26 
--- 21,36 
  # include 
  #endif
  
+ /* Convert an internet address from a printable, presentable format to 
internal
+format.
+AF is an internet address family, such as AF_INET or AF_INET6.
+SRC points to a printable representation of the address (in numeric form, 
not
+surrounded by [...], no DNS lookup is done).
+DST points to a 'struct in_addr' (for AF_INET) or 'struct in6_addr'
+(for AF_INET6).
+If the string at SRC is a valid printable representation of an address of 
the
+given family, store the internal format of the address at DST and return 1.
+If it is invalid, return 0.  Upon error, set errno and return -1.  */
  #if !HAVE_DECL_INET_PTON
  extern int inet_pton (int af, const char *restrict src, void *restrict dst);
  #endif

Re: inet_ntop module proposed patch

[Simon Josefsson]

Bruno Haible <[EMAIL PROTECTED]> writes:

> Hi Yoann and Simon,
>
> I propose to use #if HAVE_... instead of #ifdef HAVE_..., as customary in
> gnulib (with the exception of HAVE_CONFIG_H).

Oops!  Please install it.

Maybe those modules should depend on the new arpa_inet module instead
of having those HAVE_ARPA_INET_H tests at all.

/Simon

> diff -r -c3 --exclude=CVS gnulib-20060614-modified/lib/inet_ntop.h 
> gnulib-20060628-modified/lib/inet_ntop.h
> *** gnulib-20060614-modified/lib/inet_ntop.h  2006-01-23 15:52:00.0 
> +0100
> --- gnulib-20060628-modified/lib/inet_ntop.h  2006-06-29 00:15:15.0 
> +0200
> ***
> *** 17,23 
>   
>   #include 
>   #include 
> ! #ifdef HAVE_ARPA_INET_H
>   # include 
>   #endif
>   
> --- 17,23 
>   
>   #include 
>   #include 
> ! #if HAVE_ARPA_INET_H
>   # include 
>   #endif
>   

Re: [bug-gnulib] m4/isc-posix.m4

[Derek R. Price]

Bruno Haible wrote:
> Derek R. Price wrote:
>> I found this note in m4/isc-posix.m4:
>>
>> # This file is not needed with autoconf-2.53 and newer.  Remove it in 2005.
>>
>> The Autoconf 2.60 also marks AC_ISC_POSIX as obsolescent.
> 
> I will remove it in gettext-0.15.1. It will still be present in
> gettext-0.15.

What does this mean for GNULIB?  Should I remove it?

Thanks,

Derek
-- 
Derek R. Price
CVS Solutions Architect
Get CVS support at Ximbiot !
v: +1 248.835.1260
f: +1 248.835.1263

Re: [bug-gnulib] getaddrinfo: native win32 support, getnameinfo support

[Bruno Haible]

Hi Simon,

I propose these 6 patches to the recent getaddrinfo module changes:

- In getaddrinfo.h, fix an URL.

- Fix the recognition of the Win32 platform. Some compilers (Borland C)
  set __WIN32__, not _WIN32. I use a shortcut 'WIN32_NATIVE'; 'WIN32' is
  already taken: it's sometimes defined by Cygwin. Also, maybe you want
  to exclude Cygwin from this code, because Cygwin already has full
  POSIX sockets. Cf.
  http://lists.gnu.org/archive/html/bug-gnulib/2006-05/msg00070.html

- Order the three function pointers in the same order as the rest of the
  code.

- Make the use_win32_p function static. There's no other code outside using
  it, right?

- Change the parsing of a service name to reject empty strings and
  strings starting with spaces; this is would be an unnecessary extension
  to POSIX. In other words, expect the service name string to start with a
  digit. Also, reject ports > 65535. (Aren't ports limited to 65535 on
  every platform?)

- Avoid redundant casts: Even with the stricter C++ cast rules, you don't
  need to cast from X* to void* or const void *.

Bruno


diff -r -c3 --exclude=CVS gnulib-20060614-modified/lib/getaddrinfo.h 
gnulib-20060628-modified/lib/getaddrinfo.h
*** gnulib-20060614-modified/lib/getaddrinfo.h  2006-06-29 01:30:47.0 
+0200
--- gnulib-20060628-modified/lib/getaddrinfo.h  2006-06-29 00:54:43.0 
+0200
***
*** 134,140 
  # if !HAVE_DECL_GETNAMEINFO
  /* Convert socket address to printable node and service names.
 For more details, see the POSIX:2001 specification
!.  */
  extern int getnameinfo(const struct sockaddr *restrict sa, socklen_t salen,
   char *restrict node, socklen_t nodelen,
   char *restrict service, socklen_t servicelen,
--- 134,140 
  # if !HAVE_DECL_GETNAMEINFO
  /* Convert socket address to printable node and service names.
 For more details, see the POSIX:2001 specification
!.  */
  extern int getnameinfo(const struct sockaddr *restrict sa, socklen_t salen,
   char *restrict node, socklen_t nodelen,
   char *restrict service, socklen_t servicelen,
diff -r -c3 --exclude=CVS gnulib-20060614-modified/lib/getaddrinfo.c 
gnulib-20060628-modified/lib/getaddrinfo.c
*** gnulib-20060614-modified/lib/getaddrinfo.c  2006-06-29 01:30:47.0 
+0200
--- gnulib-20060628-modified/lib/getaddrinfo.c  2006-06-29 01:12:43.0 
+0200
***
*** 40,50 
  
  #include "strdup.h"
  
! #ifdef _WIN32
! typedef void WSAAPI (*freeaddrinfo_func) (struct addrinfo*);
  typedef int WSAAPI (*getaddrinfo_func) (const char*, const char*,
const struct addrinfo*,
struct addrinfo**);
  typedef int WSAAPI (*getnameinfo_func) (const struct sockaddr*,
socklen_t, char*, DWORD,
char*, DWORD, int);
--- 40,54 
  
  #include "strdup.h"
  
! #if defined _WIN32 || defined __WIN32__
! # define WIN32_NATIVE
! #endif
! 
! #ifdef WIN32_NATIVE
  typedef int WSAAPI (*getaddrinfo_func) (const char*, const char*,
const struct addrinfo*,
struct addrinfo**);
+ typedef void WSAAPI (*freeaddrinfo_func) (struct addrinfo*);
  typedef int WSAAPI (*getnameinfo_func) (const struct sockaddr*,
socklen_t, char*, DWORD,
char*, DWORD, int);
***
*** 53,59 
  static freeaddrinfo_func freeaddrinfo_ptr = NULL;
  static getnameinfo_func getnameinfo_ptr = NULL;
  
! int use_win32_p (void)
  {
static int done = 0;
HMODULE h;
--- 57,64 
  static freeaddrinfo_func freeaddrinfo_ptr = NULL;
  static getnameinfo_func getnameinfo_ptr = NULL;
  
! static int
! use_win32_p (void)
  {
static int done = 0;
HMODULE h;
***
*** 128,134 
};
  #endif
  
! #ifdef _WIN32
if (use_win32_p ())
  return getaddrinfo_ptr (nodename, servname, hints, res);
  #endif
--- 133,139 
};
  #endif
  
! #ifdef WIN32_NATIVE
if (use_win32_p ())
  return getaddrinfo_ptr (nodename, servname, hints, res);
  #endif
***
*** 162,169 
if (!se)
{
  char *c;
  port = strtoul (servname, &c, 10);
! if (*c)
return EAI_NONAME;
  port = htons (port);
}
--- 167,176 
if (!se)
{
  char *c;
+ if (!(*servname >= '0' && *servname <= '9))
+   return EAI_NONAME;
  port = strtoul (servname, &c, 10);
! if (*c || port > 0x)
return EAI_NONAME;
  port = htons (port);
}
***
*** 285,291 
  void
  freeaddrinfo (struct addrinfo *ai)
  {
! #ifdef

Re: [bug-gnulib] minimum autoconf version

[Bruno Haible]

Paul Eggert writes:

> The code currently assumes Autoconf 2.60 but could be backported easily

I think it's important to leave people a choice. Autoconf 2.60 will have
different bugs than autoconf-2.59, which had different bugs than 2.57.
I think it's fine to now drop support for autoconf-2.57 and -2.58. But
forcing people to using a specific release is creating constraints that
are weird to satisfy. For example, if someone wants to keep using
po/Makefile.in.in from gettext-0.14.x, at first sight he cannot upgrade
to autoconf-2.60 without getting warnings. (OK, he can if he uses
AC_DATAROOTDIR_CHECKED, but maybe he then falls into some bugs we don't
know about yet.)

A few years ago, the required versions of glibc and gcc were tied;
likewise the versions of autoconf and automake were constrained. These
were major annoyances. And with gnulib, we don't want to annoy people.

Bruno

Re: [bug-gnulib] proposed simplification rewrite of stdint module

[Bruno Haible]

Hi Paul,

> Here's a proposed rewrite of the stdint module that attempts to
> simplify the module

Great job! Overall, I like it.

> The basic idea is to use macros instead of typedefs.

That simplifies some of the #ifs; the other part is done by assuming
current hardware with 16 or 32 or 64-bit registers.

> #if @HAVE_STDINT_H@
> # if defined __sgi && ! defined __c99 && __STDC_VERSION__ < 199901L

Where does the __STDC_VERSION__ test come from? AFAIK, the SGI
 spews the warning if and only if   ! defined __c99
If you use a different test here, it's possible that a "gcc --std=c99" on that
platform (which does not define __c99) falls on the bad , no?

> #define _STDINT_MAX(signed, bits, zero) \

Clever!

>   ((signed) \
>? ~ _STDINT_MIN (signed, bits, zero) \
>: (((zero) + 2) << ((bits) ? (bits) - 1 : 0)) - 1)

The last line gives an integer overflow, which some compilers may rightfully
complain about. I think it will give less warnings when written as

 : zero) + 1) << ((bits) ? (bits) - 1 : 0)) - 1) * 2 + 1)

> #if LONG_MAX >> 31 >> 31 == 1

Nice trick to avoid an autoconf test! :-)

> #define int_fast8_t int8_t
> #define uint_fast8_t uint8_t
> #define int_fast16_t int16_t
> #define uint_fast16_t uint16_t
> #define int_fast32_t int32_t
> #define uint_fast32_t uint32_t

I don't agree with these choices. On SPARC, the use of 16-bit types for
computations or as a loop counter can really kill performance, because
gcc inserts two shift instructions between arithmetic operations, and
on 64-bit Alpha you similarly have added 'zap' instructions when passing
32-bit words as function arguments.

In summary, on 32-bit platforms, nowadays, 32-bit types are the safest
if you want speed. On 64-bit platform it's likely the 64-bit types, but
32-bit types are usually well supported too.

The only CPU I know for which a 16-bit loop counter is faster than a
32-bit loop counter is m68k; but it is not a CPU of "today" any more.

> #if @HAVE_LONG_LONG_INT@
> #define intmax_t long long int
> #define uintmax_t unsigned long long int
> #else
> #define intmax_t long int
> #define uintmax_t unsigned long int
> #endif

This is lacking the case for _MSC_VER. Why not use a "#ifdef int64_t"
here?

> #ifdef INT64_C
> # define INTMAX_C(x)   INT64_C(x)
> # define UINTMAX_C(x)  UINT64_C(x)

I think it's safer if this would use the same #if condition as the
definition of uintmax_t.

> #ifndef WCHAR_MIN
> #ifndef WCHAR_MAX
> #ifndef WINT_MIN
> #ifndef WINT_MAX

Why #ifndef here, and #undef for the others? I've seen a BSD system
a week ago, where wchar_t is a signed 32-bit type and WCHAR_MAX = 0x7fff
and WCHAR_MIN = 0 (!!). If you want an ISO C99 compliant , you
need to #undef the original values.

>   dnl Check for long long int.
>   AC_REQUIRE([AC_TYPE_LONG_LONG_INT])

There are compilers which accept the "long long int" syntax, but for
which "long long int" is a 32-bit type. IMO this test also needs to
check that "long long int" is longer than 32 bits or longer than "long int".

>   if test $ac_cv_header_inttypes_h = yes; then
>   if test $ac_cv_header_sys_types_h = yes; then
>   if test $ac_cv_header_stdint_h = yes; then

Can you please add comments explaining where these variable values come from?
It's not obvious.

>if eval test \"\$gl_cv_type_${gltype}_signed\" = yes; then

I got some errors when trying to use 'eval' in this way. (Sorry, I don't
remember the details.) Ended up using

eval result=\$gl_cv_type_${gltype}_signed
if test "$result" = yes; then

Simpler, less convoluted.

>   gl_cv_type_ptrdiff_t_signed=yes
>   gl_INTEGER_TYPE_SUFFIX([ptrdiff_t sig_atomic_t size_t wchar_t wint_t],
> [gl_STDINT_INCLUDES])

For completeness, this should also set

gl_cv_type_size_t_signed=no

Finally, two testsuite updates: Where it uses
_STDINT_H_HAVE_INT64
it now should say
_STDINT_H_HAVE_INT64 || defined int64_t
and similarly
_STDINT_H_HAVE_UINT64
should become
_STDINT_H_HAVE_UINT64 || defined uint64_t
And it now uses HAVE_WCHAR_T and HAVE_WINT_T, therefore modules/stdint-tests
should use m4/wchar_t.m4 and m4/wint_t.m4 and invoke these macros.

> #if @HAVE_INTTYPES_H@
>   /* In OpenBSD 3.8,  includes , which defines
>  int{8,16,32,64}_t, uint{8,16,32,64}_t and __BIT_TYPES_DEFINED__.
>   also defines intptr_t and uintptr_t.  */
> # include 
> #endif

In a few weeks, after gettext-0.15 is released, I'll also submit a rewrite
of the 'inttypes' module. The substitute  includes ,
therefore at that moment we will have to change the
   # include 
back to
   # include @FULL_PATH_INTTYPES_H@
again, to avoid circular #includes. (I already have this rewrite but I'm
holding it off until gettext-0.15 is released, otherwise we get conflicts
between gnulib-tool and gettextize.)

Bruno

Re: getaddrinfo: native win32 support, getnameinfo support

[Simon Josefsson]

Bruno Haible <[EMAIL PROTECTED]> writes:

> Hi Simon,
>
> I propose these 6 patches to the recent getaddrinfo module changes:

Hi Bruno!  All looks good to me, please install them!

/Simon

Re: inet_pton documentation

[Simon Josefsson]

Bruno Haible <[EMAIL PROTECTED]> writes:

> Hi Simon,
>
> Can we add some documentation here? I don't find that the comment in
> the implementation is clear enough.

Please install.  This is one case where I agree it is OK to put the
comment in the header file -- we shouldn't modify the source file too
much since it is from glibc.  The source file also have some
documentation already; having two documentation in the same file seems
confusing.

Thanks!

> diff -r -c3 --exclude=CVS gnulib-20060614-modified/lib/inet_pton.h 
> gnulib-20060628-modified/lib/inet_pton.h
> *** gnulib-20060614-modified/lib/inet_pton.h  2006-06-29 01:30:47.0 
> +0200
> --- gnulib-20060628-modified/lib/inet_pton.h  2006-06-29 00:32:23.0 
> +0200
> ***
> *** 21,26 
> --- 21,36 
>   # include 
>   #endif
>   
> + /* Convert an internet address from a printable, presentable format to 
> internal
> +format.
> +AF is an internet address family, such as AF_INET or AF_INET6.
> +SRC points to a printable representation of the address (in numeric 
> form, not
> +surrounded by [...], no DNS lookup is done).
> +DST points to a 'struct in_addr' (for AF_INET) or 'struct in6_addr'
> +(for AF_INET6).
> +If the string at SRC is a valid printable representation of an address 
> of the
> +given family, store the internal format of the address at DST and return 
> 1.
> +If it is invalid, return 0.  Upon error, set errno and return -1.  */
>   #if !HAVE_DECL_INET_PTON
>   extern int inet_pton (int af, const char *restrict src, void *restrict dst);
>   #endif

Re: [bug-gnulib] AC_C_CONST

[Derek R. Price]

Bruno Haible wrote:
> Derek R. Price wrote:
>>  * m4/gettext.m4: Remove references to obsolescent AC_C_CONST.
> 
> I'll do this in gettext-0.15.1.

I'm not sure how the GNULIB macro relates to gettext.  Is this a change
you'll import into GNULIB after you change gettext?

Regards,

Derek
-- 
Derek R. Price
CVS Solutions Architect
Get CVS support at Ximbiot !
v: +1 248.835.1260
f: +1 248.835.1263

Re: new module for temporary files in temporary directories

[Bruno Haible]

Paul Eggert wrote:
> Some problems I noticed:
> 
> * The GNU coding standards say that one shouldn't use "path" to
>   describe a file name; "path" should be used for things like PATH
>   instead, which are lists of file names.  Several of the comments and
>   names of functions etc should be changed accordingly.

The GNU coding standards say so when talking about documentation. Here
we are talking about _code_ (i.e. something that is invisible to the user)
that is meant to be executed on POSIX platforms, and POSIX has clear
definitions of the term "pathname" and "filename" (see also under
"pathname component").
  
http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_266

> * When 'sort' removes a temporary file in ordinary computation
>   (outside a signal handler), it wants to know if 'unlink' failed so
>   that it can issue a diagnostic (e.g., an I/O error occurred).  The
>   proposed API doesn't seem to allow for this.  Similarly for 'rmdir'.

OK, I can add a verbosity flag, that has the effect of signalling when
an 'unlink' or 'rmdir' operation fails with an error other than ENOENT.
(Since the cleanup handler is registered before the file or subdir
is created, it can happen that the cleanup handler is invoked at a
moment when the file does not yet exist. This is normal.)

> * 'sort' creates and remove temporary files in a certain order,
>   and its asymptotic performance relies on the internal data structures
>   (linked lists) accommodating this order.  I suppose I'll have to
>   review the proposed code to see whether it has similar asymptotic
>   behavior.  The basic problem here occurs when one has many, many
>   temporary files.

The module is, so far, not optimized for asymptotic performance.
How many temporary files does 'sort' use? Is more than 1 temp files
realistic (each of size > 10 MB, giving a total of 100 GB) ?

> * Why do the functions have 'queue' in their names?  Files don't
>   have to be removed in a FIFO order.

It's a pool of tasks registered for future execution. An unordered queue.
Do you know a good name for that?

Bruno

utime module

[Derek R. Price]

Since the utime module only switches on the result of
AC_FUNC_UTIME_NULL, and the Autoconf 2.60 documentation labels
AC_FUNC_UTIME_NULL as obsolescent for lack of practical porting targets,
would be okay to remove the utime module from GNULIB?

This would mean removing lib/utime.c, m4/utime.m4, & m4/utimes-null.m4.
 No modules depend on utime, so the only other modification would be
removing the references in MODULES.html.sh.

Cheers,

Derek
-- 
Derek R. Price
CVS Solutions Architect
Get CVS support at Ximbiot !
v: +1 248.835.1260
f: +1 248.835.1263

Re: utime module

[Paul Eggert]

"Derek R. Price" <[EMAIL PROTECTED]> writes:

> Since the utime module only switches on the result of
> AC_FUNC_UTIME_NULL, and the Autoconf 2.60 documentation labels
> AC_FUNC_UTIME_NULL as obsolescent for lack of practical porting targets,
> would be okay to remove the utime module from GNULIB?

This one is a bit like memcmp, since it depends on C libraries,
not on C compilers themselves.  So one possibility is to put it
on the same watch list as memcmp, exit, etc.

I think only coreutils uses this module nowadays.  Jim, do you know of
any practical porting targets where utime(..., NULL) still doesn't work?  The
last time I heard of this bug in the wild was more than ten years ago, e.g.,
.

Re: tempname.c vs. mingw

[Paul Eggert]

Eric Blake <[EMAIL PROTECTED]> writes:

> +#if ! HAVE_DECL_MKDIR
> +# if HAVE_IO_H
> +#  include 
> +# endif
> +# define mkdir ((int (*)()) _mkdir)
> +#endif

Surely this won't work if ! HAVE_DECL_MKDIR && ! HAVE_IO_H, since
_mkdir will be undefined in that case.  Also, older Unix systems lack
a mkdir declaration, but have mkdir (it may not fit the prototype,
though, so you shouldn't declare it without checking).  Also the
"#define" gives me the heebie-jeebies, since it relies on undefined
behavior (passing the wrong number of arguments to a C function).

How about something like this instead?

#if ! HAVE_DECL_MKDIR && HAVE_IO_H
# include 
static int mkdir (char const *name, mode_t mode) { return _mkdir (name); }
#endif

Other than that, it looks good to me; thanks.

Re: utime module

[Derek R. Price]

Paul Eggert wrote:
> "Derek R. Price" <[EMAIL PROTECTED]> writes:
> 
>> Since the utime module only switches on the result of
>> AC_FUNC_UTIME_NULL, and the Autoconf 2.60 documentation labels
>> AC_FUNC_UTIME_NULL as obsolescent for lack of practical porting targets,
>> would be okay to remove the utime module from GNULIB?
> 
> This one is a bit like memcmp, since it depends on C libraries,
> not on C compilers themselves.  So one possibility is to put it
> on the same watch list as memcmp, exit, etc.
> 
> I think only coreutils uses this module nowadays.  Jim, do you know of
> any practical porting targets where utime(..., NULL) still doesn't work?  The
> last time I heard of this bug in the wild was more than ten years ago, e.g.,
> .

I was assuming that Akim would have put a spy in the Autoconf test suite
to make sure it was okay to declare this macro obsolescent, but digging
into the Autoconf repository, I don't see any evidence of that.

I'll implement Jim's watch list for this one, memcmp, the rest of the
C89 functions you pointed out, and any others I notice that look promising.

Cheers,

Derek
-- 
Derek R. Price
CVS Solutions Architect
Get CVS support at Ximbiot !
v: +1 248.835.1260
f: +1 248.835.1263

Re: proposed simplification rewrite of stdint module

[Ben Pfaff]

Paul Eggert <[EMAIL PROTECTED]> writes:

> Here's a proposed rewrite of the stdint module that attempts to
> simplify the module while addressing the porting issues that have come
> up in the last week.  The basic idea is to use macros instead of
> typedefs.  I think this kind of approach would have avoided most
> (though not all) of the porting problems we've had recently.

I don't know whether it really matters in practice, but C99 says
that these types are typedefs, not macros.
-- 
"Long noun chains don't automatically imply security."
--Bruce Schneier

Re: [bug-gnulib] proposed simplification rewrite of stdint module

[Paul Eggert]

Bruno Haible <[EMAIL PROTECTED]> writes:

>> #if @HAVE_STDINT_H@
>> # if defined __sgi && ! defined __c99 && __STDC_VERSION__ < 199901L
>
> Where does the __STDC_VERSION__ test come from?

I wanted to handle the future case when SGI fixes the bug in their
system.  But you're right, this won't work with GCC today, so I'll
remove that part of the test.  We can worry about SGI future versions
later.

> The last line gives an integer overflow, which some compilers may rightfully
> complain about. I think it will give less warnings when written as
>
>  : zero) + 1) << ((bits) ? (bits) - 1 : 0)) - 1) * 2 + 1)

Hmm, that's not quite right either, surely you meant (bits) - 2.
But I now thought of a simpler definition.  _STDINT_MAX needs only
two arguments, and can be simplified to:

/* _STDINT_MAX relies on the signedness of 'zero' to return the
   correct type.  */
#define _STDINT_MAX(bits, zero) (~ _STDINT_MIN (1, bits, zero))


> on 32-bit platforms, nowadays, 32-bit types are the safest
> if you want speed. On 64-bit platform it's likely the 64-bit types, but
> 32-bit types are usually well supported too.

OK, I'll change it to this, which follows the advice you gave:

   #define int_fast8_t long int
   #define uint_fast8_t unsigned int_fast8_t
   #define int_fast16_t long int
   #define uint_fast16_t unsigned int_fast16_t
   #define int_fast32_t long int
   #define uint_fast32_t unsigned int_fast32_t

> This is lacking the case for _MSC_VER. Why not use a "#ifdef int64_t"
> here?

Thanks.  Mark D. Baushke already raised this issue via private mail
(my answer is in
)
but your suggested fix is better.

>> #ifdef INT64_C
>> # define INTMAX_C(x)   INT64_C(x)
>> # define UINTMAX_C(x)  UINT64_C(x)
>
> I think it's safer if this would use the same #if condition as the
> definition of uintmax_t.

OK, thanks, I'll do that, as follows:

   #if @HAVE_LONG_LONG_INT@
   # define INTMAX_C(x)   x##LL
   # define UINTMAX_C(x)  x##ULL
   #elif defined int64_t
   # define INTMAX_C(x)   INT64_C(x)
   # define UINTMAX_C(x)  UINT64_C(x)
   #else
   # define INTMAX_C(x)   x##L
   # define UINTMAX_C(x)  x##UL
   #endif

> Why #ifndef here, and #undef for the others? I've seen a BSD system
> a week ago, where wchar_t is a signed 32-bit type and WCHAR_MAX = 0x7fff
> and WCHAR_MIN = 0 (!!).

OK, thanks, I didn't know about that.  I'll #undef the MIN and MAX values
for wint_t, wchar_t, ptrdiff_t, size_t, sig_atomic_t.

> IMO this test also needs to
> check that "long long int" is longer than 32 bits or longer than "long int".

OK, thanks, I'll add that by modifying AC_TYPE_LONG_LONG_INT and
AC_TYPE_UNSIGNED_LONG_LONG INT.  This will require a change to
Autoconf.  In the meantime I'll update m4/longlong.m4 and
m4/ulonglong.m4 to override Autoconf 2.60, using the 2.60 API but with
the improved check.  Something like this, for example:

   AC_DEFUN([AC_TYPE_LONG_LONG_INT],
   [
 AC_CACHE_CHECK([for long long int], [ac_cv_type_long_long_int],
   [AC_LINK_IFELSE(
  [AC_LANG_PROGRAM(
 [long long int ll = 9223372036854775807ll;
  long long int nll = -9223372036854775807LL;
  typedef int a[((-9223372036854775807LL < 0
  && 0 < 9223372036854775807ll)
 ? 1 : -1)];
  int i = 63;],
 [long long int llmax = 9223372036854775807ll;
  return (ll << 63 | ll >> 63 | ll < i | ll > i
  | llmax / ll | llmax % ll);])],
  [ac_cv_type_long_long_int=yes],
  [ac_cv_type_long_long_int=no])])
 if test $ac_cv_type_long_long_int = yes; then
   AC_DEFINE([HAVE_LONG_LONG_INT], 1,
 [Define to 1 if the system has the type `long long int'.])
 fi
   ])

This will propagate into some other macros due to the name change, but
that's merely mechanical.


>>   if test $ac_cv_header_inttypes_h = yes; then
>>   if test $ac_cv_header_sys_types_h = yes; then
>>   if test $ac_cv_header_stdint_h = yes; then
>
> Can you please add comments explaining where these variable values come from?

Will do.

>>if eval test \"\$gl_cv_type_${gltype}_signed\" = yes; then
>
> I got some errors when trying to use 'eval' in this way.

Weird.  I'll rewrite it as you suggest.  If you run into it again,
can you please send a note to [EMAIL PROTECTED]  I'd like to
write it up under Shellology.

> For completeness, this should also set
>
> gl_cv_type_size_t_signed=no

Will do.

> Finally, two testsuite updates: Where it uses
> _STDINT_H_HAVE_INT64
> it now should say
> _STDINT_H_HAVE_INT64 || defined int64_t
> and similarly
> _STDINT_H_HAVE_UINT64
> should become
> _STDINT_H_HAVE_UINT64 || defined uint64_t

Hmm, _STDINT_H_HAVE_UINT64 is no longer defined.  I'll try simpling
use the C99 standard symbols, e.g., "#ifdef INT64_MAX", "#ifdef
UINT64_MAX"; that should be more robust to future changes to the

Re: [bug-gnulib] minimum autoconf version

[Paul Eggert]

Bruno Haible <[EMAIL PROTECTED]> writes:

> I think it's fine to now drop support for autoconf-2.57 and -2.58.

OK, thanks, I'll change the AC_PREREQ call to 2.59, and test under 2.59
as installed by Debian.

AC_STRUCT_TM

[Derek R. Price]

The attached patch removes reference to AC_STRUCT_TM, which is declared
obsolescent by Autoconf 2.60.  `struct tm' is also part of C89.


2006-06-29  Derek R. Price  <[EMAIL PROTECTED]>

* m4/posixtm.m4: Don't call obsolescent AC_STRUCT_TM.
* lib/posixtm.c: Assume  has struct tm.

Cheers,

Derek
-- 
Derek R. Price
CVS Solutions Architect
Get CVS support at Ximbiot !
v: +1 248.835.1260
f: +1 248.835.1263

Index: lib/posixtm.c
===
RCS file: /cvsroot/gnulib/gnulib/lib/posixtm.c,v
retrieving revision 1.22
diff -u -p -r1.22 posixtm.c
--- lib/posixtm.c   9 Jan 2006 23:13:56 -   1.22
+++ lib/posixtm.c   29 Jun 2006 18:16:58 -
@@ -31,11 +31,7 @@
 #include 
 #include 
 
-#ifdef TM_IN_SYS_TIME
-# include 
-#else
-# include 
-#endif
+#include 
 
 #include "posixtm.h"
 
Index: m4/posixtm.m4
===
RCS file: /cvsroot/gnulib/gnulib/m4/posixtm.m4,v
retrieving revision 1.4
diff -u -p -r1.4 posixtm.m4
--- m4/posixtm.m4   21 Mar 2005 22:06:27 -  1.4
+++ m4/posixtm.m4   29 Jun 2006 18:16:58 -
@@ -1,5 +1,5 @@
 # posixtm.m4 serial 4
-dnl Copyright (C) 2002, 2003, 2005 Free Software Foundation, Inc.
+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,5 +10,4 @@ AC_DEFUN([gl_POSIXTM],
   AC_LIBOBJ(posixtm)
 
   dnl Prerequisites of lib/posixtm.c.
-  AC_STRUCT_TM
 ])

Re: [bug-gnulib] m4/isc-posix.m4

[Paul Eggert]

"Derek R. Price" <[EMAIL PROTECTED]> writes:

>> I will remove it in gettext-0.15.1. It will still be present in
>> gettext-0.15.
>
> What does this mean for GNULIB?  Should I remove it?

Generally, gnulib just mirrors the latest stable gettext version.
Occasionally Bruno will make exceptions but I doubt whether this
would rise to that level of importance.

Re: [bug-gnulib] m4/isc-posix.m4

[Derek R. Price]

Paul Eggert wrote:
> "Derek R. Price" <[EMAIL PROTECTED]> writes:
> 
>>> I will remove it in gettext-0.15.1. It will still be present in
>>> gettext-0.15.
>> What does this mean for GNULIB?  Should I remove it?
> 
> Generally, gnulib just mirrors the latest stable gettext version.
> Occasionally Bruno will make exceptions but I doubt whether this
> would rise to that level of importance.

Fair enough.  Just wondering whether I should do anything other than
drop the subject.  :)

Thanks,

Derek
-- 
Derek R. Price
CVS Solutions Architect
Get CVS support at Ximbiot !
v: +1 248.835.1260
f: +1 248.835.1263

AC_HEADER_STDC

[Derek R. Price]

The attached patch removes references to AC_HEADER_STDC, marked
obsolescent in the Autoconf 2.60 release, from m4/*.m4 and the
corresponding #if STDC_HEADERS sections from lib/*.[ch].  This seems
right since GNULIB already assumes all of the headers AC_HEADER_STDC
checks for (`stdlib.h', `stdarg.h', `string.h', and `float.h').

2006-06-29  Derek R. Price  <[EMAIL PROTECTED]>

* lib/exclude.c, lib/exit.h, lib/fnmatch.c, lib/fnmatch_loop.c,
lib/getusershell.c, lib/mbswidth.c, lib/memcasecmp.c,
lib/strtod.c, lib/strtol.c, lib/xstrtol.c: Remove sections
dependent on !STDC_HEADERS.
* m4/calloc.m4, m4/exclude.m4, m4/getdate.m4, m4/gettext.m4,
m4/getusershell.m4, m4/memcasecmp.m4, m4/onceonly.m4,
m4/onceonly_2_57.m4, m4/strtod.m4, m4/strtol.m4, m4/xstrtol.m4:
Don't call obsolescent AC_HEADER_STDC.

Cheers,

Derek
-- 
Derek R. Price
CVS Solutions Architect
Get CVS support at Ximbiot !
v: +1 248.835.1260
f: +1 248.835.1263

Index: lib/exclude.c
===
RCS file: /cvsroot/gnulib/gnulib/lib/exclude.c,v
retrieving revision 1.28
diff -u -p -r1.28 exclude.c
--- lib/exclude.c   25 May 2006 07:02:07 -  1.28
+++ lib/exclude.c   29 Jun 2006 19:07:39 -
@@ -43,18 +43,6 @@
 # include "unlocked-io.h"
 #endif
 
-#if STDC_HEADERS || (! defined isascii && ! HAVE_ISASCII)
-# define IN_CTYPE_DOMAIN(c) true
-#else
-# define IN_CTYPE_DOMAIN(c) isascii (c)
-#endif
-
-static inline bool
-is_space (unsigned char c)
-{
-  return IN_CTYPE_DOMAIN (c) && isspace (c);
-}
-
 /* Non-GNU systems lack these options, so we don't need to check them.  */
 #ifndef FNM_CASEFOLD
 # define FNM_CASEFOLD 0
@@ -244,12 +232,12 @@ add_exclude_file (void (*add_func) (stru
   {
char *pattern_end = p;
 
-   if (is_space (line_end))
+   if (isspace (line_end))
  {
for (; ; pattern_end--)
  if (pattern_end == pattern)
goto next_pattern;
- else if (! is_space (pattern_end[-1]))
+ else if (! isspace (pattern_end[-1]))
break;
  }
 
Index: lib/exit.h
===
RCS file: /cvsroot/gnulib/gnulib/lib/exit.h,v
retrieving revision 1.2
diff -u -p -r1.2 exit.h
--- lib/exit.h  14 May 2005 06:03:58 -  1.2
+++ lib/exit.h  29 Jun 2006 19:07:39 -
@@ -21,7 +21,7 @@
 /* Get exit() declaration.  */
 #include 
 
-/* Some systems do not define EXIT_*, even with STDC_HEADERS.  */
+/* Some systems do not define EXIT_*, despite otherwise supporting C89.  */
 #ifndef EXIT_SUCCESS
 # define EXIT_SUCCESS 0
 #endif
Index: lib/fnmatch.c
===
RCS file: /cvsroot/gnulib/gnulib/lib/fnmatch.c,v
retrieving revision 1.33
diff -u -p -r1.33 fnmatch.c
--- lib/fnmatch.c   27 Jan 2006 18:40:27 -  1.33
+++ lib/fnmatch.c   29 Jun 2006 19:07:39 -
@@ -86,34 +86,17 @@ extern int fnmatch (const char *pattern,
 #if defined _LIBC || !defined __GNU_LIBRARY__ || !HAVE_FNMATCH_GNU
 
 
-# if defined STDC_HEADERS || !defined isascii
-#  define ISASCII(c) 1
-# else
-#  define ISASCII(c) isascii(c)
-# endif
-
 # ifdef isblank
-#  define ISBLANK(c) (ISASCII (c) && isblank (c))
+#  define ISBLANK(c) isblank(c)
 # else
 #  define ISBLANK(c) ((c) == ' ' || (c) == '\t')
 # endif
 # ifdef isgraph
-#  define ISGRAPH(c) (ISASCII (c) && isgraph (c))
+#  define ISGRAPH(c) isgraph(c)
 # else
-#  define ISGRAPH(c) (ISASCII (c) && isprint (c) && !isspace (c))
+#  define ISGRAPH(c) (isprint (c) && !isspace (c))
 # endif
 
-# define ISPRINT(c) (ISASCII (c) && isprint (c))
-# define ISDIGIT(c) (ISASCII (c) && isdigit (c))
-# define ISALNUM(c) (ISASCII (c) && isalnum (c))
-# define ISALPHA(c) (ISASCII (c) && isalpha (c))
-# define ISCNTRL(c) (ISASCII (c) && iscntrl (c))
-# define ISLOWER(c) (ISASCII (c) && islower (c))
-# define ISPUNCT(c) (ISASCII (c) && ispunct (c))
-# define ISSPACE(c) (ISASCII (c) && isspace (c))
-# define ISUPPER(c) (ISASCII (c) && isupper (c))
-# define ISXDIGIT(c) (ISASCII (c) && isxdigit (c))
-
 # define STREQ(s1, s2) ((strcmp (s1, s2) == 0))
 
 # if defined _LIBC || WIDE_CHAR_SUPPORT
Index: lib/fnmatch_loop.c
===
RCS file: /cvsroot/gnulib/gnulib/lib/fnmatch_loop.c,v
retrieving revision 1.11
diff -u -p -r1.11 fnmatch_loop.c
--- lib/fnmatch_loop.c  27 Jan 2006 18:40:27 -  1.11
+++ lib/fnmatch_loop.c  29 Jun 2006 19:07:39 -
@@ -288,18 +288,18 @@ FCT (const CHAR *pattern, const CHAR *st
  goto matched;
 # endif
 #else
-   if ((STREQ (str, L_("alnum")) && ISALNUM ((UCHAR) *n))
-   || (STREQ (str, L_("alpha")) && ISALPHA ((UCHAR) *n))
+   if ((STREQ (str, L_("alnum")) && isalnum ((UCHAR) *n))
+   || (

Last few obsolescent macros

[Derek R. Price]

Anyone have any thoughts on the last few macros declared obsolescent by
Autoconf 2.60 and used by GNULIB?  They are AC_HEADER_DIRENT,
AC_HEADER_STAT, & AC_HEADER_TIME.  Cleaning up after all three looks
worthwhile.  Removing references to AC_HEADER_DIRENT (replacing with
AC_CHECK_HEADERS_ONCE([dirent.h])) & AC_HEADER_TIME, in particular,
would result in fairly significant simplification.

I'll do the work, but I thought I'd check for potential objections first.

Cheers,

Derek
-- 
Derek R. Price
CVS Solutions Architect
Get CVS support at Ximbiot !
v: +1 248.835.1260
f: +1 248.835.1263

Re: AC_FUNC_STRFTIME

[Jim Meyering]

"Derek R. Price" <[EMAIL PROTECTED]> wrote:
> Autoconf 2.60 declares the AC_FUNC_STRFTIME macro obsolescent since
> practical porting targets without a strftime function no longer exist.
>
> 2006-06-28  Derek R. Price  <[EMAIL PROTECTED]>
>
>   * lib/strftime.c: Assume strftime() exists.
>   * m4/strftime.m4: Don't call AC_FUNC_STRFTIME.

Thanks.  I've applied that.
The only change was to increment the serial number in strftime.m4.

Re: tempname.c vs. mingw

[Eric Blake]

Paul Eggert  CS.UCLA.EDU> writes:

> > +#if ! HAVE_DECL_MKDIR
> > +# if HAVE_IO_H
> > +#  include 
> > +# endif
> > +# define mkdir ((int (*)()) _mkdir)
> > +#endif
> 
> Surely this won't work if ! HAVE_DECL_MKDIR && ! HAVE_IO_H, since
> _mkdir will be undefined in that case.

Agreed; and I used your proposed rewrite of the tighter condition.

>  Also, older Unix systems lack
> a mkdir declaration, but have mkdir (it may not fit the prototype,
> though, so you shouldn't declare it without checking).

Is that even worth bothering with, for modern portability targets?  I figure we 
can improve the module later if another host is found where it is worthwhile to 
add a workaround in sys/stat.  And when it comes to module dependencies, for 
now only mkstemp depends on the new sys_stat; we can add the dependency to 
other modules as the need arises when porting them to mingw.

>  Also the
> "#define" gives me the heebie-jeebies, since it relies on undefined
> behavior (passing the wrong number of arguments to a C function).

Well, it was the suggestion from Bruno as seen in functions.texi, and has the 
benefit that &mkdir is still a valid function pointer to the OS's exported 
function (with a static replacement function, you no longer can guarantee that 
the function pointer is the same across .o files).  But I went with your idea 
of a static method as a cleaner solution.  Besides, how often does code take 
the address of mkdir?

> 
> Other than that, it looks good to me; thanks.
> 

Checked in with the above changes.  Thanks for the review.

-- 
Eric Blake

Re: proposed simplification rewrite of stdint module

[Paul Eggert]

Ben Pfaff <[EMAIL PROTECTED]> writes:

> I don't know whether it really matters in practice, but C99 says
> that these types are typedefs, not macros.

Yes, that's a disadvantage of the new approach.  However, it's common
practice with Autoconf to use #define in this case, so we have a lot
of experience with that sort of thing.  In theory the #define's would
break a conforming program that expected a preprocessor expression
like "defined intmax_t" to return false, but this sort of thing isn't
worth worrying about in practice.

Re: tempname.c vs. mingw

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Eric Blake on 6/29/2006 4:15 PM:
> 
> Well, it was the suggestion from Bruno as seen in functions.texi, and has the 
> benefit that &mkdir is still a valid function pointer to the OS's exported 
> function (with a static replacement function, you no longer can guarantee 
> that 
> the function pointer is the same across .o files).  But I went with your idea 
> of a static method as a cleaner solution.  Besides, how often does code take 
> the address of mkdir?
> 
> Checked in with the above changes.  Thanks for the review.

Well, after using this in m4, I realized that without inline, gcc
complains when the static function is unused.  Installed this followon.

lib/ChangeLog:
2006-06-29  Eric Blake  <[EMAIL PROTECTED]>

* stat_.h (rpl_mkdir): Declare inline, to avoid warnings about
unused static function.

m4/ChangeLog:
2006-06-29  Eric Blake  <[EMAIL PROTECTED]>

* sys_stat_h.m4 (gl_HEADER_SYS_STAT_H): Use AC_C_INLINE.

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

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

iD8DBQFEpKYX84KuGfSFAYARAkNZAJ4kKHpU6jz3Uwz/euYbyLVDcmFJiACgl11N
+XRXqDVN52+NjULcncWmDN4=
=lJ+k
-END PGP SIGNATURE-
Index: lib/stat_.h
===
RCS file: /sources/gnulib/gnulib/lib/stat_.h,v
retrieving revision 1.1
diff -u -p -r1.1 stat_.h
--- lib/stat_.h 29 Jun 2006 22:17:42 -  1.1
+++ lib/stat_.h 30 Jun 2006 04:15:50 -
@@ -35,7 +35,13 @@
alias mkdir), only in the nonstandard io.h.  */
 #if ! HAVE_DECL_MKDIR && HAVE_IO_H
 # include 
-static int rpl_mkdir (char const *name, mode_t mode) { return _mkdir (name); }
+
+static inline int
+rpl_mkdir (char const *name, mode_t mode)
+{
+  return _mkdir (name);
+}
+
 # define mkdir rpl_mkdir
 #endif
 
Index: m4/sys_stat_h.m4
===
RCS file: /sources/gnulib/gnulib/m4/sys_stat_h.m4,v
retrieving revision 1.1
diff -u -p -r1.1 sys_stat_h.m4
--- m4/sys_stat_h.m429 Jun 2006 22:18:26 -  1.1
+++ m4/sys_stat_h.m430 Jun 2006 04:15:50 -
@@ -22,6 +22,7 @@ AC_DEFUN([gl_HEADER_SYS_STAT_H],
 gl_FULL_HEADER_PATH([sys/stat.h])
 FULL_PATH_SYS_STAT_H='<'$gl_cv_full_path_sys_stat_h'>'
 AC_CHECK_HEADERS([io.h])
+AC_REQUIRE([AC_C_INLINE])
 AC_SUBST([FULL_PATH_SYS_STAT_H])
 SYS_STAT_H='sys/stat.h'
   fi

Re: tempname.c vs. mingw

[Paul Eggert]

Eric Blake <[EMAIL PROTECTED]> writes:

>>  Also, older Unix systems lack
>> a mkdir declaration, but have mkdir (it may not fit the prototype,
>> though, so you shouldn't declare it without checking).
>
> Is that even worth bothering with, for modern portability targets?

Perhaps not.  You're right, we can fix this in the sys_stat module if
it comes up.  Thanks.

Re: new module for temporary files in temporary directories

[Paul Eggert]

Bruno Haible <[EMAIL PROTECTED]> writes:

> (Since the cleanup handler is registered before the file or subdir
> is created, it can happen that the cleanup handler is invoked at a
> moment when the file does not yet exist. This is normal.)

Yes, that's expected.

> The module is, so far, not optimized for asymptotic performance.
> How many temporary files does 'sort' use? Is more than 1 temp files
> realistic (each of size > 10 MB, giving a total of 100 GB) ?

Yes, I'm afraid it is.  People are sorting larger files these days,
and GNU sort doesn't always pick good sizes for temporaries.

>> * Why do the functions have 'queue' in their names?  Files don't
>>   have to be removed in a FIFO order.
>
> It's a pool of tasks registered for future execution. An unordered queue.
> Do you know a good name for that?

The function names use the verbs "enqueue" and "dequeue", not the noun
"queue".  So we don't need a noun; we need two verbs.  How about
"register" and "unregister"?  The comments say that these functions
register and unregister things, so their names might as well reflect
what they do.

After looking at the code a bit more, I have another comment -- more a
question, really.  Are all those "volatile"s really needed?

The C and POSIX standards are basically useless when it comes to
"volatile", so I was wondering what informal rules of thumb you were
using when programming, when deciding when to use "volatile" and when
not to.

This isn't really a fair question, since I ran across the same problem
with GNU "sort" and came up empty.  I still don't understand
"volatile", to be honest.  The occurrences of "volatile" in GNU sort
are sheer guesswork.  I suspect that none of them are actually needed
in practice.

The C standardization committee attempted to define the semantics of
sequence points and "volatile" in an appendix to draft C99, but after
I asked a lot of questions about it they withdrew the appendix.  (Let
this be a warning to you about trying to answer my question.  :-)

> Here we are talking about _code_ (i.e. something that is invisible
> to the user) that is meant to be executed on POSIX platforms, and
> POSIX has clear definitions of the term "pathname" and "filename"

I know about the POSIX terminology, but I think it's better to stick
with the GNU terminology, even when writing internal code.  Otherwise
I'll have to remember to switch terminologies when turning my
attention from the code to the documentation or vice versa.  It's not
a huge deal, admittedly; just one more thing to worry about.