Re: Incompatibility between current gnulib and gettext-0.14.6?
Paul Eggert <[EMAIL PROTECTED]> writes: > Eric Blake <[EMAIL PROTECTED]> writes: > >> Or you could upgrade to gettext 0.16, which is designed to work out of the >> box with autoconf 2.61, automake 1.10, and gnulib. > > That makes more sense. It'd take a lot of work to support arbitrary > combinations of Automake 1.X, Gettext 0.Y, Autoconf 2.Z, and current > Gnulib, and nobody really has time to do that. It's usually better to > build with the latest tools. > > Of course some exceptions might need to be made, but I don't know of > any reason for findutils to prefer gettext 0.14.6 over 0.16 nowadays. I agree in general, although I'd prefer to see gnulib support autoconf 2.60a, automake 1.10 and gettext 0.15 for some time more, because that is what is installed on my up-to-date Debian 'unstable' box. However, I suppose they are recent enough not to cause any problems? (CC to other lists dropped.) /Simon
Re: Incompatibility between current gnulib and gettext-0.14.6?
Simon Josefsson <[EMAIL PROTECTED]> writes: > I agree in general, although I'd prefer to see gnulib support autoconf > 2.60a, automake 1.10 and gettext 0.15 for some time more, because that > is what is installed on my up-to-date Debian 'unstable' box. Somehow I missed the release of Autoconf 2.61. So it's coming up soon for Debian unstable now... -- Peter Seebach on managing engineers: "It's like herding cats, only most of the engineers are already sick of laser pointers."
Re: coreutils-6.5: yet another C89 problem
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Matthew Woehlke <[EMAIL PROTECTED]> writes:
>
>> Ok, happen to have a quick how-to? (A cron job that *doesn't* mail me
>> unless there is a problem would be nice :-).)
>
> http://buildbot.sourceforge.net/
>
> I haven't built one myself, but others have
This will keep me from releasing decl-after-stmt code in coreutils/src:
* Makefile.maint (patch-check): Compile patched sources with
CFLAGS='-Wdeclaration-after-statement -Werror', to ensure that
no violations remain.
diff --git a/Makefile.maint b/Makefile.maint
index 8fa6f70..9400b49 100644
--- a/Makefile.maint
+++ b/Makefile.maint
@@ -334,6 +334,9 @@ patch-check:
if test "$${REGEN_PATCH+set}" = set; then \
diff -upr src src-c89 > new-diff || : ; fi
fail=0; test -s [EMAIL PROTECTED] && fail=1 || : ; \
+ rm -f src-c89/*.o || fail=1; \
+ $(MAKE) -C src-c89 CFLAGS='-g -Wdeclaration-after-statement -Werror' \
+ || fail=1; \
rm -rf src-c89 [EMAIL PROTECTED] [EMAIL PROTECTED]; \
test $$fail = 0
bug in getaddrinfo.c
The getaddrinfo.c file contains these lines within getaddrinfo(): 151if (hints && (hints->ai_flags & ~(AI_CANONNAME|AI_PASSIVE))) 152 /* FIXME: Support more flags. */ 153 return EAI_BADFLAGS; followed later by: 181if (!(hints->ai_flags & AI_NUMERICSERV)) 182 /* FIXME: Use getservbyname_r if available. */ 183 se = getservbyname (servname, proto); But to properly support this latter code, the earlier test must include the AI_NUMERICSERV flag. Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com
module for missing math.h functions?
C99 added some useful functions to math.h, such as trunc and round. Would there be objections to a module that adds implementations of those functions? I am particularly interested in those two functions, which are handy for GNU PSPP, and so I am likely to write such a module if acceptance would be likely. -- Ben Pfaff email: [EMAIL PROTECTED] web: http://benpfaff.org
Re: module for missing math.h functions?
Ben Pfaff <[EMAIL PROTECTED]> writes: > C99 added some useful functions to math.h, such as trunc and > round. Would there be objections to a module that adds > implementations of those functions? I am particularly interested > in those two functions, which are handy for GNU PSPP, and so I am > likely to write such a module if acceptance would be likely. Sounds good to me; thanks. I assume you know about doing the right thing with infinities and NaNs and with signed zeros. What implementation would you use? 'round' is trickier that it might appear at first, due to problems with internal rounding. Even 'trunc' is a bit tricky, since trunc(-0.0) should yield -0.0, not 0.0.
fix incompatibilities of regex with gcc -ansi -pedantic
I tried compiling coreutils with gcc -ansi -pedantic (ah, the good
old days!) and found some incompatibilities had crept into the
regex module. I installed this to fix them:
2006-11-26 Paul Eggert <[EMAIL PROTECTED]>
Fix some incompatibilities with gcc -ansi -pedantic.
* lib/regex.h (__restrict_arr): Don't use the [restrict] syntax
if compiling pedantically with GCC, unless it's C99 or later.
Don't trust sys/cdefs.h's definition of __restrict_arr, either, as
it mishandles gcc -ansi -pedantic as well.
* lib/regex_internal.h (re_token_t): Don't use enum bitfields
if gcc -pedantic.
* lib/regexec.c (check_node_accept_bytes): Don't use auto
initializers for struct if -pedantic, unless it's C99 or later.
Index: lib/regex.h
===
RCS file: /cvsroot/gnulib/gnulib/lib/regex.h,v
retrieving revision 1.38
diff -u -r1.38 regex.h
--- lib/regex.h 10 Aug 2006 20:08:01 - 1.38
+++ lib/regex.h 27 Nov 2006 07:15:02 -
@@ -635,14 +635,17 @@
# endif
# endif
#endif
-/* gcc 3.1 and up support the [restrict] syntax. */
-#ifndef __restrict_arr
-# if (__GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)) \
- && !defined __GNUG__
-# define __restrict_arr __restrict
-# else
-# define __restrict_arr
-# endif
+/* gcc 3.1 and up support the [restrict] syntax. Don't trust
+ sys/cdefs.h's definition of __restrict_arr, though, as it
+ mishandles gcc -ansi -pedantic. */
+#undef __restrict_arr
+#if (defined __GNUG__ \
+ || (__STDC_VERSION__ < 199901L\
+&& (__STRICT_ANSI__\
+|| (__GNUC__ < 3 || (__GNUC__ == 3 && __GNUC_MINOR__ < 1)
+# define __restrict_arr
+#else
+# define __restrict_arr __restrict
#endif
/* POSIX compatibility. */
Index: lib/regex_internal.h
===
RCS file: /cvsroot/gnulib/gnulib/lib/regex_internal.h,v
retrieving revision 1.24
diff -u -r1.24 regex_internal.h
--- lib/regex_internal.h21 Aug 2006 06:11:26 - 1.24
+++ lib/regex_internal.h27 Nov 2006 07:15:02 -
@@ -348,7 +348,7 @@
Idx idx; /* for BACK_REF */
re_context_type ctx_type; /* for ANCHOR */
} opr;
-#if __GNUC__ >= 2
+#if __GNUC__ >= 2 && !__STRICT_ANSI__
re_token_type_t type : 8;
#else
re_token_type_t type;
Index: lib/regexec.c
===
RCS file: /cvsroot/gnulib/gnulib/lib/regexec.c,v
retrieving revision 1.22
diff -u -r1.22 regexec.c
--- lib/regexec.c 5 Jun 2006 05:21:20 - 1.22
+++ lib/regexec.c 27 Nov 2006 07:15:02 -
@@ -3966,7 +3966,7 @@
# endif /* _LIBC */
{
/* match with range expression? */
-#if __GNUC__ >= 2
+#if __GNUC__ >= 2 && ! (__STDC_VERSION__ < 199901L && __STRICT_ANSI__)
wchar_t cmp_buf[] = {L'\0', L'\0', wc, L'\0', L'\0', L'\0'};
#else
wchar_t cmp_buf[] = {L'\0', L'\0', L'\0', L'\0', L'\0', L'\0'};
proposed patch to gettext.h for gcc -ansi -pedantic
gettext.h also has a problem with gcc -ansi -pedantic: it uses the [restrict] syntax in that case, but GCC complains about it since [restrict] isn't in C89. Here's a proposed patch: 2006-11-26 Paul Eggert <[EMAIL PROTECTED]> * lib/gettext.h (_LIBGETTEXT_HAVE_VARIABLE_SIZE_ARRAYS): Don't define if __STRICT_ANSI__, unless it's C99 or later, since C89 lacked support for the [restrict] syntax and gcc -ansi -pedantic complains about it. Index: lib/gettext.h === RCS file: /cvsroot/gnulib/gnulib/lib/gettext.h,v retrieving revision 1.13 diff -p -u -r1.13 gettext.h --- lib/gettext.h 10 Nov 2006 14:49:09 - 1.13 +++ lib/gettext.h 27 Nov 2006 07:17:01 - @@ -169,7 +169,9 @@ npgettext_aux (const char *domain, #include #define _LIBGETTEXT_HAVE_VARIABLE_SIZE_ARRAYS \ - (__GNUC__ >= 3 || __GNUG__ >= 2 /* || __STDC_VERSION__ >= 199901L */ ) + (((__GNUC__ >= 3 || __GNUG__ >= 2) \ +&& (__STDC_VERSION__ >= 199901L || ! __STRICT_ANSI__)) \ + /* || __STDC_VERSION__ >= 199901L */) #if !_LIBGETTEXT_HAVE_VARIABLE_SIZE_ARRAYS #include
Re: coreutils-6.5: yet another C89 problem
Jim Meyering <[EMAIL PROTECTED]> writes:
> This will keep me from releasing decl-after-stmt code in coreutils/src:
This inspired me to try harder for an automated check for departures
from C89. Here's a proposed patch that implements such a check for
coreutils, and that fixes the departures that I found. This should
supersede coreutils' patch-check rule, in the sense that it should
find everything that patch-check finds, but I left patch-check alone
for now (partly because it's faster).
This was the patch I used to find the regex incompatibilities
I fixed today in gnulib.
Also, it relies on the gettext.h patch I sent to bug-gnulib a few
minutes ago, in the sense that the resulting 'make distcheck' won't
succeed unless gettext.h is also fixed.
2006-11-26 Paul Eggert <[EMAIL PROTECTED]>
Fix some incompatibilities with gcc -ansi -pedantic.
* lib/regex.h (__restrict_arr): Don't use the [restrict] syntax
if compiling pedantically with GCC, unless it's C99 or later.
Don't trust sys/cdefs.h's definition of __restrict_arr, either, as
it mishandles gcc -ansi -pedantic as well.
* lib/regex_internal.h (re_token_t): Don't use enum bitfields
if gcc -pedantic.
* lib/regexec.c (check_node_accept_bytes): Don't use auto
initializers for struct if -pedantic, unless it's C99 or later.
diff --git a/Makefile.maint b/Makefile.maint
index 9400b49..821a53c 100644
--- a/Makefile.maint
+++ b/Makefile.maint
@@ -528,6 +528,11 @@ my-distcheck: $(local-check) $(release_a
(cd $(t) && mv $(distdir) $(distdir).old\
&& $(AMTAR) -zxf - ) < $(distdir).tar.gz
diff -ur $(t)/$(distdir).old $(t)/$(distdir)
+ cd $(t)/$(distdir) \
+ && (cd src && patch -V never --fuzz=0 )
and push @line, $_;
}
-my $last_line = pop @line;
my $indent = ' ';
-print "static char const G_line[] =\n";
+print "static char const G_line[] =\n{\n";
foreach (@line)
{
-print "$indent\"$_\\0\"\n";
+s/./'$&',/g;
+s/'\\'/''/g;
+s/'''/'\\''/g;
+print "$indent${_}0,\n";
}
-print "$indent\"$last_line\";\n";
+print "};\n";
diff --git a/src/cut.c b/src/cut.c
index 4faae4c..73277fa 100644
--- a/src/cut.c
+++ b/src/cut.c
@@ -223,6 +223,8 @@ Mandatory arguments to long options are
Use one, and only one of -b, -c or -f. Each LIST is made up of one\n\
range, or many ranges separated by commas. Selected input is written\n\
in the same order that it is read, and is written exactly once.\n\
+"), stdout);
+ fputs (_("\
Each range is one of:\n\
\n\
N N'th byte, character or field, counted from 1\n\
diff --git a/src/date.c b/src/date.c
index 187956a..2dec4c3 100644
--- a/src/date.c
+++ b/src/date.c
@@ -223,6 +223,8 @@ specifies Coordinated Universal Time. I
%Z alphabetic time zone abbreviation (e.g., EDT)\n\
\n\
By default, date pads numeric fields with zeroes.\n\
+"), stdout);
+ fputs (_("\
The following optional flags may follow `%':\n\
\n\
- (hyphen) do not pad the field\n\
diff --git a/src/dd.c b/src/dd.c
index f1dc474..3449e12 100644
--- a/src/dd.c
+++ b/src/dd.c
@@ -448,6 +448,8 @@ Each CONV symbol may be:\n\
notrunc do not truncate the output file\n\
ucase change lower case to upper case\n\
swab swap every pair of input bytes\n\
+"), stdout);
+ fputs (_("\
noerror continue after read errors\n\
sync pad every input block with NULs to ibs-size; when used\n\
with block or unblock, pad with spaces rather than NULs\n\
diff --git a/src/du.c b/src/du.c
index 5f4e796..6a4c8c7 100644
--- a/src/du.c
+++ b/src/du.c
@@ -293,6 +293,8 @@ Mandatory arguments to long options are
the apparent size is usually smaller, it may be\n\
larger due to holes in (`sparse') files, internal\n\
fragmentation, indirect blocks, and the like\n\
+"), stdout);
+ fputs (_("\
-B, --block-size=SIZE use SIZE-byte blocks\n\
-b, --bytes equivalent to `--apparent-size --block-size=1'\n\
-c, --total produce a grand total\n\
@@ -305,6 +307,8 @@ Mandatory arguments to long options are
change to be equivalent to --dereference-args (-D)\n\
-h, --human-readable print sizes in human readable format (e.g., 1K 234M
2G)\n\
--si like -h, but use powers of 1000 not 1024\n\
+"), stdout);
+ fputs (_("\
-klike --block-size=1K\n\
-l, --count-links count sizes many times if hard linked\n\
-mlike --block-size=1M\n\
diff --git a/src/ls.c b/src/ls.c
index 03164b1..63d363f 100644
--- a/src/ls.c
+++ b/src/ls.c
@@ -4270,6 +4270,8 @@ Mandatory arguments to long options are
-h, --human-readable with -l, print sizes in human readable format\n\
(e.g., 1K 234M 2G)\n\
--si lik
