gnulib changes to conform to Autoconf 2.59c rules for 'exit'
Autoconf 2.60 won't declare 'exit' for you automatically, due to severe
portability hassles in trying to do this. I installed the following
changes to gnulib to accommodate this. These changes also fix some
related portability problems that I discovered in the neighborhood,
e.g., other undeclared functions.
I'll install this into coreutils shortly.
2006-04-24 Paul Eggert <[EMAIL PROTECTED]>
* m4/fsusage.m4 (gl_FILE_SYSTEM_USAGE): Use return, not exit.
Don't assume that exit status -1 is valid.
* m4/nanosleep.m4 (gl_FUNC_NANOSLEEP): Likewise.
* m4/putenv.m4 (gl_FUNC_PUTENV): Likewise.
* m4/rmdir-errno.m4 (gl_FUNC_RMDIR_NOTEMPTY): Likewise.
* m4/readdir.m4 (GL_FUNC_READDIR): Include .
* m4/rename.m4 (vb_FUNC_RENAME): Likewise.
* m4/unlink-busy.m4 (gl_FUNC_UNLINK_BUSY_TEXT): Use AC_RUN_IFELSE,
not AC_TRY_RUN. Use return, not exit. Don't assume that
functions can be used without declaring them, or that you can
exit with status -1.
* m4/utimes-null.m4 (gl_FUNC_UTIMES_NULL): Likewise.
Index: m4/fsusage.m4
===
RCS file: /cvsroot/gnulib/gnulib/m4/fsusage.m4,v
retrieving revision 1.22
diff -p -u -r1.22 fsusage.m4
--- m4/fsusage.m4 2 Jul 2005 09:58:35 - 1.22
+++ m4/fsusage.m4 24 Apr 2006 07:34:27 -
@@ -1,7 +1,7 @@
-#serial 16
+#serial 17
# Obtaining file system usage information.
-# Copyright (C) 1997, 1998, 2000, 2001, 2003, 2004, 2005 Free Software
+# Copyright (C) 1997, 1998, 2000, 2001, 2003, 2004, 2005, 2006 Free Software
# Foundation, Inc.
#
# This file is free software; the Free Software Foundation
@@ -78,7 +78,7 @@ if test $ac_fsusage_space = no; then
{
struct statfs fsd;
fsd.f_fsize = 0;
-exit (statfs (".", &fsd, sizeof (struct statfs)));
+return statfs (".", &fsd, sizeof (struct statfs)) != 0;
}],
fu_cv_sys_stat_statfs3_osf1=yes,
fu_cv_sys_stat_statfs3_osf1=no,
@@ -110,7 +110,7 @@ member (AIX, 4.3BSD)])
{
struct statfs fsd;
fsd.f_bsize = 0;
- exit (statfs (".", &fsd));
+ return statfs (".", &fsd) != 0;
}],
fu_cv_sys_stat_statfs2_bsize=yes,
fu_cv_sys_stat_statfs2_bsize=no,
@@ -133,7 +133,7 @@ if test $ac_fsusage_space = no; then
main ()
{
struct statfs fsd;
- exit (statfs (".", &fsd, sizeof fsd, 0));
+ return statfs (".", &fsd, sizeof fsd, 0) != 0;
}],
fu_cv_sys_stat_statfs4=yes,
fu_cv_sys_stat_statfs4=no,
@@ -162,7 +162,7 @@ member (4.4BSD and NetBSD)])
{
struct statfs fsd;
fsd.f_fsize = 0;
- exit (statfs (".", &fsd));
+ return statfs (".", &fsd) != 0;
}],
fu_cv_sys_stat_statfs2_fsize=yes,
fu_cv_sys_stat_statfs2_fsize=no,
@@ -195,7 +195,7 @@ if test $ac_fsusage_space = no; then
struct fs_data fsd;
/* Ultrix's statfs returns 1 for success,
0 for not mounted, -1 for failure. */
- exit (statfs (".", &fsd) != 1);
+ return statfs (".", &fsd) != 1;
}],
fu_cv_sys_stat_fs_data=yes,
fu_cv_sys_stat_fs_data=no,
Index: m4/nanosleep.m4
===
RCS file: /cvsroot/gnulib/gnulib/m4/nanosleep.m4,v
retrieving revision 1.22
diff -p -u -r1.22 nanosleep.m4
--- m4/nanosleep.m4 2 Mar 2006 07:36:41 - 1.22
+++ m4/nanosleep.m4 24 Apr 2006 07:34:27 -
@@ -1,4 +1,4 @@
-#serial 15
+#serial 16
dnl From Jim Meyering.
dnl Check for the nanosleep function.
@@ -51,7 +51,7 @@ AC_DEFUN([gl_FUNC_NANOSLEEP],
struct timespec ts_sleep, ts_remaining;
ts_sleep.tv_sec = 0;
ts_sleep.tv_nsec = 1;
- exit (nanosleep (&ts_sleep, &ts_remaining) == 0 ? 0 : 1);
+ return nanosleep (&ts_sleep, &ts_remaining) != 0;
}
],
jm_cv_func_nanosleep_works=yes,
Index: m4/putenv.m4
===
RCS file: /cvsroot/gnulib/gnulib/m4/putenv.m4,v
retrieving revision 1.16
diff -p -u -r1.16 putenv.m4
--- m4/putenv.m423 Sep 2005 04:15:13 - 1.16
+++ m4/putenv.m424 Apr 2006 07:34:27 -
@@ -1,5 +1,5 @@
-# putenv.m4 serial 10
-dnl Copyright (C) 2002, 2003, 2004, 2005 Free Software Foundation, Inc.
+# putenv.m4 serial 11
+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.
@@ -17,17 +17,17 @@ AC_DEFUN([gl_FUNC_PUTENV],
{
/* Put it in env. */
if (putenv ("CONFTEST_putenv=val"))
-exit (1);
+return 1;
/* Try to remove it. */
if (putenv ("CONFTEST_putenv"))
-exit (1);
+return 1;
/* Make sure it was deleted. */
if (getenv ("CONFTEST_putenv") != 0)
-exit (1);
+return 1;
- exit (0);
+ return 0;
}
],
Re: gnulib changes to conform to Autoconf 2.59c rules for 'exit'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paul Eggert on 4/24/2006 1:38 AM:
> Autoconf 2.60 won't declare 'exit' for you automatically, due to severe
> portability hassles in trying to do this. I installed the following
> changes to gnulib to accommodate this. These changes also fix some
> related portability problems that I discovered in the neighborhood,
> e.g., other undeclared functions.
Mostly good.
>
> Index: m4/unlink-busy.m4
> ===
> RCS file: /cvsroot/gnulib/gnulib/m4/unlink-busy.m4,v
> retrieving revision 1.5
> diff -p -u -r1.5 unlink-busy.m4
> --- m4/unlink-busy.m4 23 Jan 2005 08:06:57 - 1.5
> +++ m4/unlink-busy.m4 24 Apr 2006 07:34:27 -
> @@ -14,16 +14,16 @@ AC_DEFUN([gl_FUNC_UNLINK_BUSY_TEXT],
>AC_CACHE_CHECK([whether a running program can be unlinked],
> jm_cv_func_unlink_busy_text,
> [
> - AC_TRY_RUN([
> -main (argc, argv)
> - int argc;
> - char **argv;
> -{
> - if (!argc)
> -exit (-1);
> - exit (unlink (argv[0]));
> -}
> - ],
> + AC_RUN_IFELSE(
> +[AC_LANG_SOURCE(
> + [AC_INCLUDES_DEFAULT
> + int
> + main (argc, argv)
> + int argc;
> + char **argv;
However, why are you still using K&R here? Doesn't gnulib assume C89 or
better; and shouldn't tests be made to work with C++ as a C compiler when
possible?
- --
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
iD8DBQFETLK884KuGfSFAYARAn+eAJ4jmjsJFL0/PQEWNmlsPSrYNusl9gCgpW3W
8BIgiNf4tR5hDKWgpV5it/s=
=pbaA
-END PGP SIGNATURE-
Re: [bug-gnulib] gnulib-tool basics
Karl Berry wrote: > First, regarding gnulib-tool --help. > > --update isn't mentioned under "Operation modes:", although it is one > of the usages. I'm adding this doc: --update update the current package, restore files omitted from CVS > I suggest mentioning that --import can also be used for updating, > something like this (as I understand it from gnulib-tool.texi): > --import import the given modules into the current package; > if no modules are specified, update the > current package. I'll better write it this way: --import import the given modules into the current package; if no modules are specified, update the current package from the current gnulib The idea is that there are two meanings of "update", one related to CVS and the other related to newer versions of gnulib, and the two require slightly different logic. Like autopoint vs. gettextize. Currently "gnulib-tool --import" and "gnulib-tool --update" do the same; this will change when ChangeLog update support is added. > Second, I tried gnulib-tool --dry-run --update and got this: > > gnulib-tool: invalid options for 'update' mode > Try 'gnulib-tool --help' for more information. > If you really want to modify the gnulib configuration of your project, > you need to use 'gnulib --import' - at your own risk! > > I don't want to modify the configuration ... Did you pass other options than --dry-run --update, such as --lib, --source-base, --m4-base, --tests-base, --aux-dir, --with-tests, --avoid, --lgpl, --macro-prefix? These options are only supported for --import, not --update. > Third, I tried gnulib-tool --dry-run --import and got this output: > Module list with included dependencies: > > File list: > lib/dummy.c > m4/onceonly_2_57.m4 > Create directory ./lib > Create directory ./m4 > cp: cannot create regular file `./lib/dummy.c.tmp': No such file or > directory > gnulib-tool: *** failed > gnulib-tool: *** Stop. Fixed. Thanks for the report. Bruno
Re: [bug-gnulib] libopts and gnulib?
Karl Berry wrote on 2006-02-13:
> Bruce Korb implemented a library for straightforward config file
> parsing (among other things). We thought it would make sense to use it
> for GNU Hello, as an example of how it can be done.
How come so few programs use this libopts? Let me look at the syntax of
the various .??* files in my home directory.
Plain list of keyword / value pairs:
.RealNetworks_RealMediaSDK_60
.RealNetworks_RealPlayer_60
.RealNetworks_RealShared_00
.appletviewer
.asadminprefs
.emiclockrc
.flexlmrc
.jaxe
.kapptemplaterc
.lincityrc
.lynxrc
.mailcap
.mainactorrc
.mcoprc
.mh_profile
.mtvrc
.pinerc
.tkcvs
.urlview
.xtalkrc
X11 resources syntax:
.Xdefaults
.Xresources
.acrorc
.gv
.nedit
.weblink
List of keyword / value pairs, with groups and parametrized keywords:
.fvwmrc
Nested groups of C-like compound statements with braces and semicolons:
.balsarc
Keywords with nested groups of C-like compound statements as values:
.twmrc
Parametrized keywords with nested groups of C-like compound statements as
values:
.gtkrc
Windows ini syntax ([Group]s of Keyword=Value statements):
.XaraLX
.dmrc
.kderc
.realplayerrc
.rpmfind
.serc
.sversionrc
.thotrc
.uitrc.*
.yuditrc
Other groups of keyword / value pairs:
.autom4te.cfg
Scripting language with at least conditional statements:
shell:
.bashrc
.profile
.xim
.xinitrc
.xserverrc
.xsession
Lisp:
.clinit.cl
.clisprc
.sbclrc
.talkrc
Emacs-Lisp:
.emacs
.emacs-places
vim:
.exrc
.vimrc
C-like:
.xcoralrc
Other:
.fpc.cfg
.inputrc
XML:
.com.zerog.registry.xml
.fonts.conf
List of numbers:
.clockrc
Single identifier:
.craftyrc
.wmrc
Other custom text format:
.Bfs
.DCOPserver
.MCOP-random-seed
.Xmodmap
.addressbook.lu
.dvipsrc
.fonts.cache-1
.gcalrc
.gtk_qt_engine_rc
.install4j
.ispell_english
.jazz
.kermrc
.lyxrc
.mime.types
.muttrc
.nc_keys
.rhosts
.stonxrc
.tex
.valgrind.supp
.viminfo
.workmanrc
.xmbdfedrc
.zsh
Binary format:
.B.blend
.Bfont
.ICEauthority
.Xauthority
.esd_auth
.fterc
.tamaga.dat
It appears that different programs have wildly different needs in this area...
> Of course, it involves a new Autoconf macro to test whether the library
> is available. And of course again, I don't want that macro to live in
> GNU Hello, since the goal is not Hello functionality, it's to be an
> example. So I want it to be in a common place. Which I guess is
> gnulib.
Why not have libopts itself provide and install the autoconf macro that
recognizes it?
> +AC_DEFUN([ag_FIND_LIBOPTS],
> +[if test "X${ac_cv_header_autoopts_options_h}" == Xno
> +then
> + :
> +else
> + f=`autoopts-config cflags` 2>/dev/null
> + test X"${f}" = X && f=`libopts-config cflags` 2>/dev/null
These xyz-config scripts have two flaws by design:
1) They don't support using the library with a different compiler than the
one that built it. Indeed, the CFLAGS that are supported by one compiler
are not supported by other compilers. Likewise for the "-Wl,-R/usr/lib"
option reported as being present in `autoopts-config ldflags`: it does
not work when the compiler is not gcc.
2) They expect to be found in PATH. I.e. in order to use packages installed
in /foo/bar, it is no longer sufficient to set
CPPFLAGS=-I/foo/bar/include
LDFLAGS=-L/foo/bar/lib
but it's also needed to set
PATH=/foo/bar/bin:$PATH
Better use the AC_LIB_LINKFLAGS or AC_LIB_HAVE_LINKFLAGS macro from gnulib.
It doesn't have these flaws.
Bruno
Re: [bug-gnulib] Re: warning in AC_CHECK_DECL
Paul Eggert wrote on 2006-02-17: > > Either we need to update the various gnulib macros > > borrowed from CVS autoconf to override bugs in autoconf 2.59, or we need > > to release autoconf 2.60. > > We should do both, since we can't assume 2.60 will be adopted right > away. What changes need to be made, for this particular issue, to > both programs? I brought over Eric's change to gnulib: 2006-03-04 Eric Blake <[EMAIL PROTECTED]> * strerror_r.m4 (AC_FUNC_STRERROR_R): Avoid unused variable warning. *** m4/strerror_r.m4.bak2005-01-26 17:51:26.0 +0100 --- m4/strerror_r.m42006-04-24 00:36:14.0 +0200 *** *** 25,30 --- 25,31 char buf[100]; char x = *strerror_r (0, buf, sizeof buf); char *p = strerror_r (0, buf, sizeof buf); + return !p || x; ]])], ac_cv_func_strerror_r_char_p=yes) else
Re: [bug-gnulib] Re: translations
Sergey Poznyakoff wrote on 2006-02-25: > They should all go through TP, certainly. Apart from the reasons, listed > by Jim, there are two more: > > - TP checks that the translator fills assignment papers, which is > especially important for GNU programs. > - Other translators from the submitter's team have a chance to revise > his work and help him. One more reason: - Avoid duplicated work by translators. For example, a few years ago, I was dumb enough to accept a Japanese translation for gettext directly, and a year later or so, another translator, this time in the Japanese translation team, did the same work again. This was frustrating for all sides. Bruno
Re: [bug-gnulib] Re: translations
Paul Eggert wrote on 2006-02-26: > While we're on the subject, is the translation project on hiatus right > now? They haven't updated the Bison .pot file even though I sent them > email thirteen days ago about the Bison 2.1a version (a version > generated principally in order to get translations), and pinged them > again about it five days ago. Because of the delay I am currently > tempted to release Bison 2.2 untranslated. Unfortunately there were two hiati periods in the TP ca. a month ago. It appears to be fixed now. The ping/complaint address is translation at iro.umontreal.ca or, if you want a little more audience, translation-i18n at lists.sourceforge.net. Bruno
Re: [bug-gnulib] fwriteerror() interface
Ben Pfaff wrote on 2006-02-27:
> I'm not sure I understand the fwriteerror() interface.
The basic idea is to be able to write:
output_file = fopen (file_name, "w");
if (output_file == NULL)
error (EXIT_FAILURE, errno, _("error while opening \"%s\" for writing"),
file_name);
... /* Lots of fputc and fprintf calls to output_file */
/* Make sure nothing went wrong. */
if (fwriteerror (output_file))
error (EXIT_FAILURE, errno, _("error while writing \"%s\" file"),
file_name);
The function fwriteerror does everything that's necessary.
> As I read
> the function comment, fwriteerror() should always close the
> stream provided to it (except in the case of stdout). But the
> implementation does not close the stream if an error was reported
> on the stream.
True. I probably missed that because in my uses of fwriteerror(),
I use error (EXIT_FAILURE ...) in case of failure, and the state of
the stream doesn't matter in this case.
Thanks!
2006-04-23 Bruno Haible <[EMAIL PROTECTED]>
* fwriteerror.c (fwriteerror): Call fclose also when an error
condition was already detected.
Reported by Ben Pfaff <[EMAIL PROTECTED]>.
*** fwriteerror.c.bak 2005-09-21 13:08:20.0 +0200
--- fwriteerror.c 2006-04-24 01:38:14.0 +0200
***
*** 1,5
/* Detect write error on a stream.
!Copyright (C) 2003-2005 Free Software Foundation, Inc.
Written by Bruno Haible <[EMAIL PROTECTED]>, 2003.
This program is free software; you can redistribute it and/or modify
--- 1,5
/* Detect write error on a stream.
!Copyright (C) 2003-2006 Free Software Foundation, Inc.
Written by Bruno Haible <[EMAIL PROTECTED]>, 2003.
This program is free software; you can redistribute it and/or modify
***
*** 47,64
if (ferror (fp))
{
if (fflush (fp))
! return -1; /* errno is set here */
/* The stream had an error earlier, but its errno was lost. If the
error was not temporary, we can get the same errno by writing and
flushing one more byte. We can do so because at this point the
stream's contents is garbage anyway. */
if (fputc ('\0', fp) == EOF)
! return -1; /* errno is set here */
if (fflush (fp))
! return -1; /* errno is set here */
/* Give up on errno. */
errno = 0;
! return -1;
}
/* If we are closing stdout, don't attempt to do it later again. */
--- 47,72
if (ferror (fp))
{
if (fflush (fp))
! goto close_preserving_errno; /* errno is set here */
/* The stream had an error earlier, but its errno was lost. If the
error was not temporary, we can get the same errno by writing and
flushing one more byte. We can do so because at this point the
stream's contents is garbage anyway. */
if (fputc ('\0', fp) == EOF)
! goto close_preserving_errno; /* errno is set here */
if (fflush (fp))
! goto close_preserving_errno; /* errno is set here */
/* Give up on errno. */
errno = 0;
! close_preserving_errno:
! /* There's an error. Nevertheless call fclose(fp), for consistency
!with the other cases. */
! {
! int saved_errno = errno;
! fclose (fp);
! errno = saved_errno;
! return -1;
! }
}
/* If we are closing stdout, don't attempt to do it later again. */
Re: [bug-gnulib] poll.h replacement
Ralf Wildenhues wrote on 2006-03-03: > On powerpc-ibm-aix5.3.0.0, poll is not deemed acceptable: the test in > m4/poll.m4 fails because polling on /dev/null does not work. It does > work to poll on regular files, though. Polling on /dev/tty does not > work either. Thanks for the report. I'm changing poll.m4 so that when cross-compiling (i.e. when the direct test with /dev/null or /dev/tty is not possible), the test fails for AIX. Bruno
Re: [bug-gnulib] poll.h replacement
Ralf Wildenhues wrote on 2006-03-03: > the test is fine, but the build fails later: > > | xlc -DHAVE_CONFIG_H -DEXEEXT=\"\" -DEXEEXT=\"\" > -DLIBDIR=\"/usr/local/lib\" -I. -I../../dummy-0/lib -I..-D_THREAD_SAFE > -g -c ../../dummy-0/lib/poll.c > | "../../dummy-0/lib/poll.c", line 54.1: 1506-343 (S) Redeclaration of > rpl_poll differs from previous declaration on line 119 of > "/usr/include/sys/poll.h". > | "../../dummy-0/lib/poll.c", line 54.1: 1506-381 (I) The type "void*" of > parameter 1 in the prototype declaration is not compatible with the > corresponding parameter type "struct pollfd*" in the nonprototype declaration. > > because /usr/include/poll.h exists and thus the replacement header is > not added (earlier in gl_FUNC_POLL). The patch below adds it anyway in > case we deem poll() inacceptable. Thanks. I agree with you that AIX should be treated like MacOS X here. (The bug on MacOS X led to very strange behaviour of GNU clisp on MacOS X when stdin was redirected from a pipe; similar brokenness would likely happen on AIX.) With your patch in, the variable POLL_H is modified 37 lines after it has already been AC_SUBSTed. To keep the macro maintainable, I rearrange it a bit. Bruno 2006-04-23 Bruno Haible <[EMAIL PROTECTED]> * poll.m4 (gl_FUNC_POLL): Rearrange code, so that POLL_H gets assigned exactly once. *** poll.m4.bak 2006-04-24 01:46:18.0 +0200 --- poll.m4 2006-04-24 01:57:49.0 +0200 *** *** 8,19 [ AC_CHECK_HEADERS(poll.h) if test "$ac_cv_header_poll_h" = no; then ! POLL_H=poll.h else - POLL_H= - fi - AC_SUBST([POLL_H]) - AC_CHECK_FUNC(poll, [# Check whether poll() works on special files (like /dev/null) and # and ttys (like /dev/tty). On MacOS X 10.4.0 and AIX 5.3, it doesn't. --- 8,15 [ AC_CHECK_HEADERS(poll.h) if test "$ac_cv_header_poll_h" = no; then ! gl_cv_func_poll=no else AC_CHECK_FUNC(poll, [# Check whether poll() works on special files (like /dev/null) and # and ttys (like /dev/tty). On MacOS X 10.4.0 and AIX 5.3, it doesn't. *** *** 53,70 This is MacOSX or AIX #endif ], [gl_cv_func_poll=no], [gl_cv_func_poll=yes])])]) if test $gl_cv_func_poll = yes; then AC_DEFINE([HAVE_POLL], 1, [Define to 1 if you have the 'poll' function and it works.]) ! fi ! ! if test $gl_cv_func_poll = no; then ! POLL_H=poll.h # Avoid differing declaration from a system header. AC_LIBOBJ(poll) AC_DEFINE(poll, rpl_poll, [Define to poll if the replacement function should be used.]) gl_PREREQ_POLL fi ]) # Prerequisites of lib/poll.c. --- 49,67 This is MacOSX or AIX #endif ], [gl_cv_func_poll=no], [gl_cv_func_poll=yes])])]) + fi if test $gl_cv_func_poll = yes; then + POLL_H= AC_DEFINE([HAVE_POLL], 1, [Define to 1 if you have the 'poll' function and it works.]) ! else ! POLL_H=poll.h AC_LIBOBJ(poll) AC_DEFINE(poll, rpl_poll, [Define to poll if the replacement function should be used.]) gl_PREREQ_POLL fi + AC_SUBST([POLL_H]) ]) # Prerequisites of lib/poll.c.
Re: [bug-gnulib] support for AM_CPPFLAGS
Claudio Fontana wrote on 2006-03-04: > while trying to improve current support in gnulib for internal gettext, > I produced this patch, which I use successfully in the packages I > maintain to support per-package additions to AM_CPPFLAGS. > > The patch is a unified p1 diff. > I suggest this for inclusion in the gnulib CVS. Thanks, I've applied your patch, with some comments in modules/gettext. Bruno
Re: [bug-gnulib] more unistd improvements
Paul Eggert wrote on 2006-03-08: > I installed these I-hope-obvious improvements to the unistd module. > I didn't touch the modules Bruno maintains, which might also benefit > from the unistd module. Thanks. This 'unistd' module is the best invention since . I'm applying the same change to all modules borrowed from gettext, except 'setenv' (which is also used for the "relocatable" facility and therefore cannot assume the full gnulib infrastructure). Bruno 2006-04-23 Bruno Haible <[EMAIL PROTECTED]> * copy-file.c: Include unconditionally. * execute.c: Likewise. * fatal-signal.c: Likewise. * findprog.c: Likewise. * mkdtemp.c: Likewise. * pipe.h: Likewise. * pipe.c: Likewise. * wait-process.h: Likewise. 2006-04-23 Bruno Haible <[EMAIL PROTECTED]> * modules/copy-file: Depend on unistd. * modules/execute: Likewise. * modules/fatal-signal: Likewise. * modules/findprog: Likewise. * modules/mkdtemp : Likewise. * modules/pipe: Likewise. * modules/wait-process: Likewise. *** copy-file.c.bak 2005-09-21 13:08:20.0 +0200 --- copy-file.c 2006-04-24 03:49:35.0 +0200 *** *** 1,5 /* Copying of files. !Copyright (C) 2001-2003 Free Software Foundation, Inc. Written by Bruno Haible <[EMAIL PROTECTED]>, 2001. This program is free software; you can redistribute it and/or modify --- 1,5 /* Copying of files. !Copyright (C) 2001-2003, 2006 Free Software Foundation, Inc. Written by Bruno Haible <[EMAIL PROTECTED]>, 2001. This program is free software; you can redistribute it and/or modify *** *** 28,37 #include #include #include ! ! #ifdef HAVE_UNISTD_H ! # include ! #endif #if HAVE_UTIME || HAVE_UTIMES # if HAVE_UTIME_H --- 28,34 #include #include #include ! #include #if HAVE_UTIME || HAVE_UTIMES # if HAVE_UTIME_H *** execute.c.bak 2005-05-14 15:46:40.0 +0200 --- execute.c 2006-04-24 03:49:50.0 +0200 *** *** 1,5 /* Creation of autonomous subprocesses. !Copyright (C) 2001-2004 Free Software Foundation, Inc. Written by Bruno Haible <[EMAIL PROTECTED]>, 2001. This program is free software; you can redistribute it and/or modify --- 1,5 /* Creation of autonomous subprocesses. !Copyright (C) 2001-2004, 2006 Free Software Foundation, Inc. Written by Bruno Haible <[EMAIL PROTECTED]>, 2001. This program is free software; you can redistribute it and/or modify *** *** 29,38 #include #include #include ! ! #ifdef HAVE_UNISTD_H ! # include ! #endif #include "error.h" #include "exit.h" --- 29,35 #include #include #include ! #include #include "error.h" #include "exit.h" *** fatal-signal.c.bak 2005-09-21 13:08:20.0 +0200 --- fatal-signal.c 2006-04-24 03:50:30.0 +0200 *** *** 1,5 /* Emergency actions in case of a fatal signal. !Copyright (C) 2003-2004 Free Software Foundation, Inc. Written by Bruno Haible <[EMAIL PROTECTED]>, 2003. This program is free software; you can redistribute it and/or modify --- 1,5 /* Emergency actions in case of a fatal signal. !Copyright (C) 2003-2004, 2006 Free Software Foundation, Inc. Written by Bruno Haible <[EMAIL PROTECTED]>, 2003. This program is free software; you can redistribute it and/or modify *** *** 28,36 #include #include #include ! #if HAVE_UNISTD_H ! # include ! #endif #include "xalloc.h" --- 28,34 #include #include #include ! #include #include "xalloc.h" *** findprog.c.bak 2005-09-21 13:08:20.0 +0200 --- findprog.c 2006-04-24 03:50:45.0 +0200 *** *** 1,5 /* Locating a program in PATH. !Copyright (C) 2001-2004 Free Software Foundation, Inc. Written by Bruno Haible <[EMAIL PROTECTED]>, 2001. This program is free software; you can redistribute it and/or modify --- 1,5 /* Locating a program in PATH. !Copyright (C) 2001-2004, 2006 Free Software Foundation, Inc. Written by Bruno Haible <[EMAIL PROTECTED]>, 2001. This program is free software; you can redistribute it and/or modify *** *** 27,36 #include #include #include ! ! #ifdef HAVE_UNISTD_H ! # include ! #endif #include "xalloc.h" #include "pathname.h" --- 27,33 #include #include #include ! #include #include "xalloc.h" #include "pathname.h" *** mkdtemp.c.bak 2006-03-29 14:45:39.0 +0200 --- mkdtemp.c 2006-04-24 03:51:12.0 +0200 *** *** 1,4 ! /* Copyright (C) 1999, 2001-2003 Free Software Foundation, Inc. This file is part of the GNU C Library. This program is free software; you can redistribute it and/or modify --- 1,4 !
Re: [bug-gnulib] removing asctime_r, ctime_r from the time_r module
Paul Eggert wrote on 2006-03-10: > I recently redisovered the fact that asctime_r and ctime_r, like > asctime and ctime, are unsafe functions in the same sense that gets is > unsafe: they can overrun their output buffers and there's no simple > way for the user to detect in advance whether this will happen. So > GNU apps shouldn't use these functions, and I propose that we remove > these function emulations from gnulib, as follows. Any objections? Unlike gets() and the termcap functions, these functions don't need a buffer of arbitrary size. Only the initially specified size was too small. The functions would be OK to use in GNU programs if a buffer of size 100 was used rather than a buffer of size 26, no? Bruno
Re: [bug-gnulib] What happened to latest versions of GNU Patch?
Antonio Diaz Diaz wrote on 2006-03-16: > By the way. Just now I have found the file patch-2.5.9.tar.gz (date > 1-Jun-2004) in the directory ftp://alpha.gnu.org/gnu/diffutils/ after > spending more than ten hours patching and cleaning patch-2.5.4 (the > latest stable release). :-( When looking for the newest version of a GNU package, looking on alpha.gnu.org was the preferred way ca. 10 or 5 years ago. Nowadays most GNU projects have a publicly accessible CVS (most at savannah.gnu.org, some at sourceforge.net or other sites); this is where you should look for newest sources. If you don't find nothing there, take a look at the Debian packages; Debian also maintains some packages that have no official maintainer. But I agree with you: the relation between GNU patch and GNU diffutils is not clear when you look at websites looking for 'patch' but don't know about the diffutils. Bruno
Re: [bug-gnulib] removing asctime_r, ctime_r from the time_r module
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 4/24/2006 6:12 AM: > Paul Eggert wrote on 2006-03-10: >> I recently redisovered the fact that asctime_r and ctime_r, like >> asctime and ctime, are unsafe functions in the same sense that gets is >> unsafe: they can overrun their output buffers and there's no simple >> way for the user to detect in advance whether this will happen. So >> GNU apps shouldn't use these functions, and I propose that we remove >> these function emulations from gnulib, as follows. Any objections? > > Unlike gets() and the termcap functions, these functions don't need a buffer > of arbitrary size. Only the initially specified size was too small. The > functions would be OK to use in GNU programs if a buffer of size 100 was > used rather than a buffer of size 26, no? That would work to avoid overflow, but then you are wasting buffer space in the majority of usage patterns. Besides, as the Austin group has remarked, asctime_r and ctime_r also suffer from the fact that they do not honor i18n, and have proposed to obsolete them in the next version of POSIX even though they are still standardized by C99. So you are better off teaching programmers the mindset of using strftime anyways, even if buffer overflow can be avoided with asctime or ctime. - -- 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 iD8DBQFETMYA84KuGfSFAYARAqimAJwJcwigiN7otc2XlQjnm31+a6IppQCg0+jN MNhfxM+sEyBOwk+3QR1IWJ4= =hvZm -END PGP SIGNATURE-
Re: [bug-gnulib] libopts and gnulib?
On 4/24/06, Bruno Haible <[EMAIL PROTECTED]> wrote:
Karl Berry wrote on 2006-02-13:> Bruce Korb implemented a library for straightforward config file
> parsing (among other things). We thought it would make sense to use it> for GNU Hello, as an example of how it can be done.How come so few programs use this libopts? Let me look at the syntax ofthe various .??* files in my home directory.
I do not think it is due to lack of support for any given format (see below).
More likely, it is little known and once a project has a .ini file parser, why
bother with the trouble to replace it? The idea I think is to make it known that
there is a library around that will enable you to pull configuration information
from a config file without having to write your own config file parser or use
an XML library. (Most folks hate writing XML anyway.)
> Plain list of keyword / value pairs:
check. It is supported.
X11 resources syntax:
Yep
List of keyword / value pairs, with groups and parametrized keywords:
Also
Nested groups of C-like compound statements with braces and semicolons:
Nope. :(
> Keywords with nested groups of C-like compound statements as values:
XML is accepted. That is compound.
> Windows ini syntax ([Group]s of Keyword=Value statements):
Yep.
> Other groups of keyword / value pairs:
No idea. If the syntax can be expressed as:
value-name white-space value
or
value-name optional-space intro-character optional-space value
then the data can be sucked up and delivered in a digested form to the program.
> Scripting language with at least conditional statements:
Clearly not.
> XML:
Yep.
> List of numbers:
I doubt it could be easily supported.
> Single identifier:No sweat.
> Other custom text format:Don't know. Not likely.
> Binary format:Certainly not.> It appears that different programs have wildly different needs in this area...
I was not claiming that it would solve all .ini file problems for all programs.
Simply that programs with modest needs for name/value pairs could use
the library. It would make handling the data somewhat easier. The real
ultimate benefit is to be able to configure the run of a program with command
line options, environment variables and .ini/.rc files equivalently. But, of
course, that requires more than just libopts.
> Of course, it involves a new Autoconf macro to test whether the library> is available. And of course again, I don't want that macro to live in> GNU Hello, since the goal is not Hello functionality, it's to be an
> example. So I want it to be in a common place. Which I guess is> gnulib.Why not have libopts itself provide and install the autoconf macro thatrecognizes it?> +AC_DEFUN([ag_FIND_LIBOPTS],
> +[if test "X${ac_cv_header_autoopts_options_h}" == Xno> +then> + :> +else> + f=`autoopts-config cflags` 2>/dev/null> + test X"${f}" = X && f=`libopts-config cflags` 2>/dev/null
These xyz-config scripts have two flaws by design:1) They don't support using the library with a different compiler than the one that built it. Indeed, the CFLAGS that are supported by one compiler
are not supported by other compilers. Likewise for the "-Wl,-R/usr/lib" option reported as being present in `autoopts-config ldflags`: it does not work when the compiler is not gcc.
``when the compiler is different from the one used to build autoopts''.
Completely true. I sure haven't a clue what to do about it. Other than
put the burden on the guy who wants to use the different compiler.
(You can specify your own linkage options, of course, but they won't
be gotten so easily from the xxx-config script.)
2) They expect to be found in PATH. I.e. in order to use packages installed in /foo/bar, it is no longer sufficient to setCPPFLAGS=-I/foo/bar/includeLDFLAGS=-L/foo/bar/lib but it's also needed to set
PATH=/foo/bar/bin:$PATHBetter use the AC_LIB_LINKFLAGS or AC_LIB_HAVE_LINKFLAGS macro from gnulib.It doesn't have these flaws.
I'll happily use or adapt anything anybody suggests. Thank you for the suggestion!
Regards, Bruce.
Re: [bug-gnulib] fwriteerror() interface
In the latest patch, those three gotos confused me. Part of the
confusion is due to uses like 'if (fflush (fp))' which are of course
valid but which I find a bit hard to read at first. Also, the
comment's "contents is" is not quite grammatical, and the comment is a
bit overconfident about getting the "same errno".
How about this (untested) patch to make the code a bit more readable?
2006-04-24 Paul Eggert <[EMAIL PROTECTED]>
* fwriteerror.c (fwriteerror): Rewrite to avoid gotos.
*** fwriteerror.c Mon Apr 24 10:32:45 2006
--- /tmp/fwriteerror.c Mon Apr 24 11:15:01 2006
*** fwriteerror (FILE *fp)
*** 46,72
if (ferror (fp))
{
- if (fflush (fp))
- goto close_preserving_errno; /* errno is set here */
/* The stream had an error earlier, but its errno was lost. If the
!error was not temporary, we can get the same errno by writing and
flushing one more byte. We can do so because at this point the
!stream's contents is garbage anyway. */
! if (fputc ('\0', fp) == EOF)
! goto close_preserving_errno; /* errno is set here */
! if (fflush (fp))
! goto close_preserving_errno; /* errno is set here */
! /* Give up on errno. */
! errno = 0;
! close_preserving_errno:
! /* There's an error. Nevertheless call fclose(fp), for consistency
!with the other cases. */
! {
! int saved_errno = errno;
! fclose (fp);
! errno = saved_errno;
! return -1;
! }
}
/* If we are closing stdout, don't attempt to do it later again. */
--- 46,65
if (ferror (fp))
{
/* The stream had an error earlier, but its errno was lost. If the
!error was not temporary, we can usually get a useful errno by
!flushing the file, or, if that doesn't work, by writing and
flushing one more byte. We can do so because at this point the
!stream contains garbage anyway. */
! int saved_errno =
! (fflush (fp) != 0 || fputc ('\0', fp) == EOF || fflush (fp) != 0
!? errno
!: 0);
!
! /* Close the file, for consistency with the other cases. */
! fclose (fp);
! errno = saved_errno;
! return -1;
}
/* If we are closing stdout, don't attempt to do it later again. */
Re: [bug-gnulib] fwriteerror() interface
Paul Eggert <[EMAIL PROTECTED]> writes: > In the latest patch, those three gotos confused me. Part of the > confusion is due to uses like 'if (fflush (fp))' which are of course > valid but which I find a bit hard to read at first. Also, the > comment's "contents is" is not quite grammatical, and the comment is a > bit overconfident about getting the "same errno". For what it's worth, I do find Paul's version to be a little more readable. Bruno, thanks for looking at this. -- Ben Pfaff email: [EMAIL PROTECTED] web: http://benpfaff.org
Re: gnulib changes to conform to Autoconf 2.59c rules for 'exit'
Eric Blake <[EMAIL PROTECTED]> writes:
> Doesn't gnulib assume C89 or better; and shouldn't tests be made to
> work with C++ as a C compiler when possible?
Thanks, I installed this as well (in coreutils and gnulib).
2006-04-24 Paul Eggert <[EMAIL PROTECTED]>
* m4/unlink-busy.m4 (gl_FUNC_UNLINK_BUSY_TEXT): Use prototype
to define main with arguments, for C++. Reported by Eric Blake.
* m4/c-stack.m4 (AC_SYS_XSI_STACK_OVERFLOW_HEURISTIC):
Prefer 'int main ()' to 'int main (void)', for C++.
* m4/getcwd-path-max.m4 (gl_FUNC_GETCWD_PATH_MAX): Likewise.
* m4/fsusage.m4 (gl_FILE_SYSTEM_USAGE): Specify a return type
for 'main', for C99 and C++.
Index: m4/c-stack.m4
===
RCS file: /cvsroot/gnulib/gnulib/m4/c-stack.m4,v
retrieving revision 1.5
diff -p -u -r1.5 c-stack.m4
--- m4/c-stack.m4 23 Jan 2005 08:06:57 - 1.5
+++ m4/c-stack.m4 24 Apr 2006 17:45:12 -
@@ -66,7 +66,7 @@ AC_DEFUN([AC_SYS_XSI_STACK_OVERFLOW_HEUR
}
static int
-c_stack_action (void)
+c_stack_action ()
{
stack_t st;
struct sigaction act;
@@ -94,7 +94,7 @@ AC_DEFUN([AC_SYS_XSI_STACK_OVERFLOW_HEUR
}
int
-main (void)
+main ()
{
#if HAVE_SETRLIMIT && defined RLIMIT_STACK
/* Before starting the endless recursion, try to be friendly
Index: m4/fsusage.m4
===
RCS file: /cvsroot/gnulib/gnulib/m4/fsusage.m4,v
retrieving revision 1.23
diff -p -u -r1.23 fsusage.m4
--- m4/fsusage.m4 24 Apr 2006 07:35:24 - 1.23
+++ m4/fsusage.m4 24 Apr 2006 17:45:13 -
@@ -74,6 +74,7 @@ if test $ac_fsusage_space = no; then
#include
#include
#include
+ int
main ()
{
struct statfs fsd;
@@ -106,6 +107,7 @@ member (AIX, 4.3BSD)])
#ifdef HAVE_SYS_VFS_H
#include
#endif
+ int
main ()
{
struct statfs fsd;
@@ -130,6 +132,7 @@ if test $ac_fsusage_space = no; then
AC_CACHE_VAL(fu_cv_sys_stat_statfs4,
[AC_TRY_RUN([#include
#include
+ int
main ()
{
struct statfs fsd;
@@ -158,6 +161,7 @@ member (4.4BSD and NetBSD)])
#ifdef HAVE_SYS_MOUNT_H
#include
#endif
+ int
main ()
{
struct statfs fsd;
@@ -190,6 +194,7 @@ if test $ac_fsusage_space = no; then
#ifdef HAVE_SYS_FS_TYPES_H
#include
#endif
+ int
main ()
{
struct fs_data fsd;
Index: m4/getcwd-path-max.m4
===
RCS file: /cvsroot/gnulib/gnulib/m4/getcwd-path-max.m4,v
retrieving revision 1.7
diff -p -u -r1.7 getcwd-path-max.m4
--- m4/getcwd-path-max.m4 2 Jul 2005 09:58:35 - 1.7
+++ m4/getcwd-path-max.m4 24 Apr 2006 17:45:13 -
@@ -61,7 +61,7 @@ AC_DEFUN([gl_FUNC_GETCWD_PATH_MAX],
#define BUF_SLOP 20
int
-main (void)
+main ()
{
#ifndef PATH_MAX
/* The Hurd doesn't define this, so getcwd can't exhibit the bug --
Index: m4/unlink-busy.m4
===
RCS file: /cvsroot/gnulib/gnulib/m4/unlink-busy.m4,v
retrieving revision 1.6
diff -p -u -r1.6 unlink-busy.m4
--- m4/unlink-busy.m4 24 Apr 2006 07:35:24 - 1.6
+++ m4/unlink-busy.m4 24 Apr 2006 17:45:13 -
@@ -18,9 +18,7 @@ AC_DEFUN([gl_FUNC_UNLINK_BUSY_TEXT],
[AC_LANG_SOURCE(
[AC_INCLUDES_DEFAULT
int
- main (argc, argv)
- int argc;
- char **argv;
+ main (int argc, char **argv)
{
return !argc || unlink (argv[0]) != 0;
}])],
Re: [bug-gnulib] removing asctime_r, ctime_r from the time_r module
Bruno Haible <[EMAIL PROTECTED]> writes: > Unlike gets() and the termcap functions, these functions don't need a buffer > of arbitrary size. Only the initially specified size was too small. The > functions would be OK to use in GNU programs if a buffer of size 100 was > used rather than a buffer of size 26, no? Yes and no. In a practical sense, I doubt whether any implementation today will overrun a buffer of size 100. However, in practice many C implementations get it wrong anyway, so we still shouldn't encourage the use of these functions. Either their ctime/ctime_r implementations assume that localtime/localtime_r will always succeed (so they dereference a NULL pointer), or they generate incorrect (but fits-in-buffer) output for out-of-range time stamps. For example, the safe time_t range in Solaris is only the years 1900 through . ctime_r and asctime_r return NULL with errno==EOVERFLOW for years past , but they silently generate the wrong string for years before 1900. For example, on my 64-bit Solaris 10 host using UTC, for the time stamp -429496729 ctime_r and asctime_r generate the string "Sun Nov 24 17:31:44 1933" even though the correct year is 1833. For the time stamp -549755813888 they generate the string "Fri Dec 5 11:41:52 19 ." (no buffer overflow, but quite wrong!) even though the correct year is -15452. It's OK to use ctime/asctime/etc. if you know that the time stamp is in a safe range for the current C library, but determining the safe range for an arbitrary C library is fairly tricky, and I don't think it's worth the hassle. (Recent-enough glibc is always safe, but most GNU code wants to run elsewhere too.) The next POSIX will allow the current Solaris behavior, along with worse behaviors, so I think it's better if we wash our hands of these functions entirely. asctime and ctime are only historical curiosities now, and asctime_r and ctime_r are well-intentioned mistakes.
new module: iconvstring
Hi,
This module 'iconvstring' is in use in GNU gettext in 4 places. It is an
easy-to-use iconv() wrapper, like the 'iconvme' module. The difference is
that 'iconvstring' uses an iconv_t descriptor, rather than two encoding names,
and is therefore suitable for converting a whole lot of strings, without needing
to re-open a conversion descriptor for each string.
Nothing against Simon's 'iconvme' module - it is very nice. It is just that
sometimes you need one, sometimes the other.
Bruno
= modules/iconvstring
===
Description:
Character set conversion of strings made easy and fast, uses iconv.
Files:
lib/iconvstring.h
lib/iconvstring.c
m4/iconvstring.m4
Depends-on:
iconv
xalloc
configure.ac:
gl_ICONVSTRING
Makefile.am:
lib_SOURCES += iconvstring.h iconvstring.c
lib_LIBADD += $(LTLIBICONV)
Include:
"iconvstring.h"
License:
GPL
Maintainer:
Bruno Haible
= lib/iconvstring.h
===
/* Charset conversion.
Copyright (C) 2001-2003, 2006 Free Software Foundation, Inc.
Written by Bruno Haible <[EMAIL PROTECTED]>, 2001.
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 _ICONVSTRING_H
#define _ICONVSTRING_H
#include
#if HAVE_ICONV
#include
#endif
#ifdef __cplusplus
extern "C" {
#endif
#if HAVE_ICONV
/* Convert an entire string from one encoding to another, using iconv.
*RESULTP should initially contain NULL or malloced memory block.
Return value: 0 if successful, otherwise -1 and errno set.
If successful, the resulting string is stored in *RESULTP and its length
in *LENGTHP. */
extern int iconv_string (iconv_t cd, const char *start, const char *end,
char **resultp, size_t *lengthp);
#endif
#ifdef __cplusplus
}
#endif
#endif /* _ICONVSTRING_H */
= lib/iconvstring.c
===
/* Charset conversion.
Copyright (C) 2001-2003, 2006 Free Software Foundation, Inc.
Written by Bruno Haible <[EMAIL PROTECTED]>, 2001.
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. */
#ifdef HAVE_CONFIG_H
# include "config.h"
#endif
/* Specification. */
#include "iconvstring.h"
#include
#include
#if HAVE_ICONV
# include
#endif
#include "xalloc.h"
#if HAVE_ICONV
/* Converts an entire string from one encoding to another, using iconv.
Return value: 0 if successful, otherwise -1 and errno set. */
int
iconv_string (iconv_t cd, const char *start, const char *end,
char **resultp, size_t *lengthp)
{
#define tmpbufsize 4096
size_t length;
char *result;
/* Avoid glibc-2.1 bug and Solaris 2.7-2.9 bug. */
# if defined _LIBICONV_VERSION \
|| !((__GLIBC__ - 0 == 2 && __GLIBC_MINOR__ - 0 <= 1) || defined __sun)
/* Set to the initial state. */
iconv (cd, NULL, NULL, NULL, NULL);
# endif
/* Determine the length we need. */
{
size_t count = 0;
char tmpbuf[tmpbufsize];
const char *inptr = start;
size_t insize = end - start;
while (insize > 0)
{
char *outptr = tmpbuf;
size_t outsize = tmpbufsize;
size_t res = iconv (cd,
(ICONV_CONST char **) &inptr, &insize,
&outptr, &outsize);
if (res == (size_t)(-1))
{
if (errno == E2BIG)
;
else if (errno == EINVAL)
break;
else
return -1;
}
# if !defined _LIBICONV_VERSION && (defined sgi || defined __sgi)
/* Irix iconv() inserts a NUL byte if it cannot convert. */
else if (res > 0)
return -1;
# endif
cou
badly sorted #include directives
gnulib-tool appears to blindly sort the list of #include directives it prints. When the list contains #if...#endif, that makes the output funny, e.g.: You may need to add #include directives for the following .h files. #endif #if HAVE_MBRTOWC #if HAVE_WCHAR_H && HAVE_WCTYPE_H #include "c-ctype.h" #include "c-strtod.h" #include "error.h" [...] Of course, it's harmless, but it looks funny. I don't know whether the problem is in gnulib-tool or the modules that are sticking conditional inclusion directives in the list of headers. -- "I knew it was a bad sign when I drove through Hell (MI) on Wednesday and there was snow on the ground and all the standing water had a layer of ice on the surface... Yes folks, Hell has frozen over and my cable modem *still* wasn't working..." --Ed Glowacki
