Re: new warnings in mktime.c
Jim Meyering [EMAIL PROTECTED] writes: Anyway, I installed this patch into coreutils. Can you please try it with your GCC? If it pacifies your GCC I'll propagate it into gnulib and glibc. It does. Thanks! OK, I installed it. I also started the ball rolling on propagating the changes into glibc; see http://sources.redhat.com/bugzilla/show_bug.cgi?id=1033. ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: libtool 2.1a failed mdemo-make.test on Solaris
[ this thread starts at
http://lists.gnu.org/archive/html/libtool/2005-06/msg00169.html ]
Hi Sven, others,
* Sven Verdoolaege wrote on Thu, Jun 23, 2005 at 09:11:36AM CEST:
On Thu, Jun 23, 2005 at 08:31:48AM +0200, Ralf Wildenhues wrote:
It's this version that fails on solaris.
Let's see: ls libltdl/argz.h created by running `make' in $top_builddir?
Yes. I ran make check without a make first.
This seems to work on Linux...
Yes, but that works only because GNU/Linux has argz.h.
Running make first makes tests/mdemo-make.test pass on Solaris.
Ah, ok. Thanks for this report. It's a bit tricky to reproduce: You
need a system which has no argz.h, then configure, then `make check'
without prior make. If you had ever run `make' before in this build
tree, even after `make clean' the dependency information is stored in
libltdl/.deps/*.Plo, and thus hides this bug.
Now the gnulib snippet in libltdl/Makefile.am leaves us with the
possibility of using the lib_OBJECTS variable to fix this(?).
Several questions (thus the crosspost to all of these lists):
- Is it ok/supposed by gnulib to use lib_OBJECTS for this?
- Is it ok by Automake to use the *_OBJECTS variables it created,
i.e., may they be treates as exported interface?
all-local cannot be used as it is executed too late. We could, however,
just require the user to type `make' before `make check'. Ugly.
Or call `$(MAKE) all-local' from mdemo first, and have a trivial
all-local target in libltdl, if above requests are not confirmed.
Ugly as well.
FYI: libtool/tests/mdemo/Makefile.am has this:
| libmlib_la_SOURCES = mlib.c
| libmlib_la_LIBADD = @LIBLTDL@ -dlopen foo1.la -dlopen libfoo2.la
| libmlib_la_LDFLAGS = -no-undefined
| libmlib_la_DEPENDENCIES = @LIBLTDL@ libsub.la foo1.la libfoo2.la
| ## use @LIBLTDL@ because some broken makes do not accept macros in targets
| ## we can only do this because our LIBLTDL does not contain ${top_builddir}
| top_distdir = ../..
| @LIBLTDL@: $(top_distdir)/libtool $(top_distdir)/libltdl/libtool \
| $(top_distdir)/libltdl/config.h $(srcdir)/$(top_distdir)/libltdl/ltdl.c \
| $(srcdir)/$(top_distdir)/libltdl/ltdl.h
| (cd $(top_distdir)/libltdl; $(MAKE) `echo $(LIBLTDL) | sed
's,.*\.\./libltdl/,,g'`)
and libltdl/Makefile.am has this:
| ## --- ##
| ## Gnulib Makefile.am snippets ##
| ## --- ##
|
| ## ((( gnulib module argz
| BUILT_SOURCES += $(ARGZ_H)
| EXTRA_DIST += argz_.h
|
| # We need the following in order to create an argz.h when the system
| # doesn't have one that works with the given compiler.
| all-local $(lib_OBJECTS): $(ARGZ_H)
| argz.h: argz_.h
| cp $(srcdir)/argz_.h [EMAIL PROTECTED]
| mv [EMAIL PROTECTED] $@
| MOSTLYCLEANFILES += argz.h argz.h-t
| ## ))) gnulib module argz
and the objects below libltdl will all depend on argz.h.
Thanks,
Ralf
Proposed patch:
Index: libltdl/Makefile.am
===
RCS file: /cvsroot/libtool/libtool/libltdl/Makefile.am,v
retrieving revision 1.80
diff -u -r1.80 Makefile.am
--- libltdl/Makefile.am 22 Apr 2005 10:10:30 - 1.80
+++ libltdl/Makefile.am 23 Jun 2005 08:35:27 -
@@ -102,6 +102,17 @@
## Make sure these will be cleaned even when they're not built by default:
CLEANFILES = libltdl.la libltdlc.la libdlloader.la
+## Make sure argz.h will be created before it is needed:
+lib_OBJECTS = \
+ $(dlopen_la_OBJECTS) \
+ $(dld_link_la_OBJECTS) \
+ $(dyld_la_OBJECTS) \
+ $(load_add_on_la_OBJECTS) \
+ $(loadlibrary_la_OBJECTS) \
+ $(shl_load_la_OBJECTS) \
+ $(libltdl_la_OBJECTS) \
+ $(libltdlc_la_OBJECTS)
+
## --- ##
## Gnulib Makefile.am snippets ##
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: warning: comparison is always false due to limited range of data type
Paul Eggert [EMAIL PROTECTED] wrote: It will take a while for this fix to propagate, though. In the meantime, why not modify the definition of xalloc_oversized(n,s) to always return 0 if if s is a constant and if the size of n is such that the comparison cannot possibly fail. Something like this? (completely untested): 2005-06-22 Paul Eggert [EMAIL PROTECTED] * xalloc.h: Work around a bogus GCC 4.0.0 warning comparison is always false due to limited range of data type. Problem reported by Oskar Liljeblad. (xalloc_lt, xalloc_lt_always_false): New macros. (xalloc_oversized): Use them. --- xalloc.h 2005-05-14 01:02:58 -0700 +++ /tmp/xalloc.h 2005-06-22 13:53:19 -0700 @@ -56,6 +56,22 @@ void *x2nrealloc (void *p, size_t *pn, s void *xmemdup (void const *p, size_t s); char *xstrdup (char const *str); +/* Work around a bogus GCC 4.0.0 warning comparison is always false + due to limited range of data type. */ + +# define xalloc_lt(m, n) (! xalloc_lt_always_false (m, n) (m) (n)) +# if __GNUC__ 4 +# define xalloc_lt_always_false(a, b) 0 +# else +# ifndef CHAR_BIT +# include limits.h +# endif +# define xalloc_lt_always_false(m, n) \ + (__builtin_constant_p (m) \ + sizeof (n) sizeof (size_t)\ + (size_t) 1 (sizeof (n) * CHAR_BIT) = (m)) \ +# endif Nice try. That fixes the problem in quotearg.c, but provokes new warnings from gcc-4.0.1 (even on 32-bit systems): xmalloc.c: In function 'xnmalloc_inline': xmalloc.c:49: warning: left shift count = width of type xmalloc.c: In function 'xnrealloc_inline': xmalloc.c:74: warning: left shift count = width of type It looks like these warnings appear only with -O :-) Then I realized that we could avoid the shift count trouble by using TYPE_MAXIMUM (__typeof__ (n)) since this is gcc-4 specific: (in which case, this part sizeof (n) sizeof (size_t) is probably not necessary, but I left it in anyhow) Index: lib/xalloc.h === RCS file: /fetish/cu/lib/xalloc.h,v retrieving revision 1.27 diff -u -p -r1.27 xalloc.h --- lib/xalloc.h14 May 2005 07:58:07 - 1.27 +++ lib/xalloc.h23 Jun 2005 07:24:53 - @@ -56,6 +56,23 @@ void *x2nrealloc (void *p, size_t *pn, s void *xmemdup (void const *p, size_t s); char *xstrdup (char const *str); +/* Work around a bogus GCC 4.0.0 warning comparison is always false + due to limited range of data type. */ + +# define xalloc_lt(m, n) (! xalloc_lt_always_false (m, n) (m) (n)) +# if __GNUC__ 4 +# define xalloc_lt_always_false(a, b) 0 +# else +# ifndef CHAR_BIT +# include limits.h +# endif +# include intprops.h +# define xalloc_lt_always_false(m, n) \ + (__builtin_constant_p (m) \ + sizeof (n) sizeof (size_t) \ + TYPE_MAXIMUM (__typeof__ (n)) = (m)) +# endif + /* Return 1 if an array of N objects, each of size S, cannot exist due to size arithmetic overflow. S must be positive and N must be nonnegative. This is a macro, not an inline function, so that it @@ -69,7 +86,8 @@ char *xstrdup (char const *str); exactly-SIZE_MAX allocations on such hosts; this avoids a test and branch when S is known to be 1. */ # define xalloc_oversized(n, s) \ -((size_t) (sizeof (ptrdiff_t) = sizeof (size_t) ? -1 : -2) / (s) (n)) +xalloc_lt ((size_t) (sizeof(ptrdiff_t) = sizeof(size_t) ? -1 : -2) / (s), \ + n) # ifdef __cplusplus } But that didn't help. All it did was get me back to the `comparison always fails' warning. I confirmed that even with #define xalloc_lt_always_false(a, b) 1 we'd still get that warning. So what we really want is a way to tell gcc that we know what we're doing in a particular expression (or module or file) so it doesn't emit that particular warning. Better still would be an option to tell GCC not to bother us with warnings in any expression that it is going to optimize away. ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
canon-host.c disagreement (gnulib vs coreutils); zero initializers
I noticed the following disagreement between gnulib and coreutils:
--- gnulib/lib/canon-host.c 2005-05-13 23:03:57 -0700
+++ cu/lib/canon-host.c 2005-05-14 00:58:06 -0700
@@ -54,8 +54,9 @@ canon_host (char const *host)
#if HAVE_GETADDRINFO
{
-struct addrinfo hint = { 0 };
+struct addrinfo hint;
struct addrinfo *res = NULL;
+memset (hint, 0, sizeof hint);
hint.ai_flags = AI_CANONNAME;
if (getaddrinfo (host, NULL, hint, res) == 0)
{
I assume that this was due to a warning from gcc -W about a missing
initializer. But I prefer the gnulib style: it's easier to read.
How about if we just ask people to not use gcc -W?
While we're on the subject, I've noticed that glibc is now using this style:
struct addrinfo hint = { 0, };
The extra comma is an indication to the reader that we know there are
missing zeros, and don't care. This style can be used for any object
in C89, e.g.:
mbstate_t initial_state = { 0, };
where we don't know whether mbstate_t is a structure, or an integer,
and the code works either way.
So, I propose that we make the following patch to gnulib, and propagate
this to coreutils:
2005-06-23 Paul Eggert [EMAIL PROTECTED]
* canon-host.c (canon-host): Append trailing , to 0 in
initializer of struct addrinfo, as an indication that we don't
care how many members the structure has.
--- gnulib/lib/canon-host.c 2005-05-13 23:03:57 -0700
+++ fixed-gnulib/lib/canon-host.c 2005-06-23 16:06:21 -0700
@@ -54,7 +54,7 @@ canon_host (char const *host)
#if HAVE_GETADDRINFO
{
-struct addrinfo hint = { 0 };
+struct addrinfo hint = { 0, };
struct addrinfo *res = NULL;
hint.ai_flags = AI_CANONNAME;
if (getaddrinfo (host, NULL, hint, res) == 0)
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
[EMAIL PROTECTED]: Re: quotation characters]
Here are rms's comments on our draft about the quote character stuff.
1) I don't know how to address his problem with domain at hand, please help?
2) I hope that if I point the preferably, and that gcc is using
'...', and that the rest of the world thinks ' is the standard, he
will let the text pass. Are there other arguments that might
persuade him?
3) I deleted the sentence. Draft appended.
Thanks,
k
Date: Sun, 12 Jun 2005 15:57:57 -0400
From: Richard Stallman [EMAIL PROTECTED]
To: [EMAIL PROTECTED] (Karl Berry)
Subject: Re: quotation characters
Sticking to the ASCII character set (plain text, 7-bit characters) is
preferred in GNU source code comments, text documents, and other
contexts, unless there is good reason to do something else because of
the domain at hand.
I am not sure what the domain at hand means. Please look for some
other way to say whatever it is.
In the C locale, GNU programs should stick to plain ASCII for
quotation characters in messages to users: preferably 0x60 (`) for
left quotes and 0x27 (') for right quotes. If using ` is unacceptable
in your application, other possibilities are using ' for both opening
and closing, or 0x22 () for both opening and closing. It is ok, but
not required, to use locale-specific quotes in other locales.
The @uref{http://www.gnu.org/software/gnulib/, Gnulib} @code{quote}
and @code{quotearg} modules provide a reasonably straightforward way
to support locale-specific quote characters, as well as taking care of
other issues, such as quoting a filename that itself contains a quote
character. See the Gnulib documentation for usage details.
I thought we were going to tell people to use `quote',
not just mention it as a possibility.
Latin1 does have paired standalone accents, but it seems
wrong in principle to abuse them as quotes.
We should not say this is a matter of principle.
It is purely a practical matter.
--
@node Character set
@section Character set
@cindex character set
@cindex encodings
@cindex ASCII characters
@cindex non-ASCII characters
Sticking to the ASCII character set (plain text, 7-bit characters) is
preferred in GNU source code comments, text documents, and other
contexts, unless there is good reason to do something else because of
the domain at hand.
If you need to use non-ASCII characters, for example to represent
names of contributors, you should normally stick with one encoding, as
one cannot in general mix encodings reliably.
@node Quote characters
@section Quote characters
@cindex quote characters
In the C locale, GNU programs should stick to plain ASCII for
quotation characters in messages to users: preferably 0x60 (`) for
left quotes and 0x27 (') for right quotes. If using ` is unacceptable
in your application, other possibilities are using ' for both opening
and closing, or 0x22 () for both opening and closing. It is ok, but
not required, to use locale-specific quotes in other locales.
The @pxxref{http://www.gnu.org/software/gnulib/, Gnulib} @code{quote}
and @code{quotearg} modules provide a reasonably straightforward way
to support locale-specific quote characters, as well as taking care of
other issues, such as quoting a filename that itself contains a quote
character. See the Gnulib documentation for usage details.
In any case, the documentation for your program should clearly specify
how it does quoting, if different than the preferred method of ` and
'. This is especially important if the output of your program is ever
likely to be parsed by another program.
Quotation characters are a difficult area in the computing world at this
time: there are no true left or right quote characters in ASCII, or even
Latin1; the ` character we use was standardized as a grave accent.
However, Latin1 is still not universally usable.
Unicode contains the unambiguous quote characters required, and its
common encoding UTF-8 is upward compatible with [EMAIL PROTECTED] However,
Unicode and UTF-8 are not universally well-supported, either.
This may change over the next few years, and then we will revisit
this.
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: FYI: Minor patch to glob_.h
Derek Price [EMAIL PROTECTED] writes: Do you want me to keep sending FYI's to this list for this sort of minor change? Yes, please. ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: [EMAIL PROTECTED]: Re: quotation characters]
[EMAIL PROTECTED] (Karl Berry) writes: Here are rms's comments on our draft about the quote character stuff. 1) I don't know how to address his problem with domain at hand, please help? How about changing this: Sticking to the ASCII character set (plain text, 7-bit characters) is preferred in GNU source code comments, text documents, and other contexts, unless there is good reason to do something else because of the domain at hand. If you need to use non-ASCII characters, for example to represent names of contributors, you should normally stick with one encoding, as one cannot in general mix encodings reliably. to this (changebars at left): Sticking to the ASCII character set (plain text, 7-bit characters) is preferred in GNU source code comments, text documents, and other contexts, unless there is good reason to do something else because of | the application domain. For example, if source code deals with | the French Revolutionary calendar, it is OK if its literal strings | contain accented characters in month names like ``Flor@'eal''. | Also, it is OK to use non-ASCII characters to represent proper | names of contributors in change logs. | If you need to use non-ASCII characters, you should normally stick | with one encoding, as one cannot in general mix encodings reliably. I chose the French Revolutionary calendar as the example partly because emacs/lisp/calendar/cal-french.el is a precedent here. 2) I hope that if I point the preferably, and that gcc is using '...', and that the rest of the world thinks ' is the standard, he will let the text pass. Are there other arguments that might persuade him? I assume you mean punt the 'preferably'? But you can remind him that quote doesn't suffice for all applications. In particular, it isn't reentrant. Implementations that can assume a garbage collector (GCC is one example these days) should probably use something else, e.g., quotearg. ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
