Re: new module for temporary files in temporary directories

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 optimi

Re: tempname.c vs. mingw

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 righ

Re: tempname.c vs. mingw

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

Re: proposed simplification rewrite of stdint module

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 exper

Re: tempname.c vs. mingw

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 yo

Re: AC_FUNC_STRFTIME

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

Last few obsolescent macros

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([dire

AC_HEADER_STDC

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'

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

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 Br

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

"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

AC_STRUCT_TM

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

Re: proposed simplification rewrite of stdint module

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 hav

Re: utime module

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

Re: tempname.c vs. mingw

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 mk

Re: [bug-gnulib] minimum autoconf version

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.

Re: utime module

"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?

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

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

utime module

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, & m

Re: new module for temporary files in temporary directories

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 chang

Re: [bug-gnulib] AC_C_CONST

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

Re: inet_pton documentation

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

Re: getaddrinfo: native win32 support, getnameinfo support

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: [bug-gnulib] proposed simplification rewrite of stdint module

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 re

Re: [bug-gnulib] minimum autoconf version

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

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

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 b

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

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

Re: inet_ntop module proposed patch

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 t

inet_pton documentation

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

Re: tempname.c vs. mingw

-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

inet_ntop module proposed patch

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

Re: [bug-gnulib] Re: AC_FUNC_STRFTIME

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 +++ mod

Re: [bug-gnulib] AC_C_CONST

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] m4/isc-posix.m4

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: memcmp module

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 a

Re: wcwidth module license change

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

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

Re: c-bs-a

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, De

wcwidth module license change

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