Dave Love [EMAIL PROTECTED] wrote:
gnulib-tool sucked in xmalloc from something else and that failed to
build because xalloc-die was missing. This fixed it:
--- xalloc.~1.15.~Sat Apr 16 22:19:07 2005
+++ xallocMon May 9 10:50:13 2005
@@ -7,6 +7,7 @@
m4/xalloc.m4
Depends-on:
Hi Bruno,
2005-05-13 Bruno Haible [EMAIL PROTECTED]
* stdint_.h (int64_t, uint64_t, int_least64_t, uint_least64_t,
int_fast64_t, uint_fast64_t, intmax_t, uintmax_t, INT64_MIN, INT64_MAX,
UINT64_MAX, INT_LEAST64_MIN, INT_LEAST64_MAX, UINT_LEAST64_MAX,
Yoann Vandoorselaere [EMAIL PROTECTED] wrote:
...
The other files are not hidden :)
They're part of coreutils.
I will try by using these. Note that coreutils contain no fts.m4. I will
You'll find it in the CVS repository for the project on Savannah:
savannah.gnu.org/projects/coreutils
Bruno Haible [EMAIL PROTECTED] wrote:
For those modules which implement some functionality specified by POSIX,
I propose to add a reference to the POSIX spec as an URL. This is a handy
reference.
See attached patch. Files affected:
getaddrinfo.h (Simon Josefsson)
getcwd.h (all)
Hi Karl,
Here's a nit:
[EMAIL PROTECTED] (Karl Berry) wrote:
...
The @uref{http://www.gnu.org/software/gnulib/, Gnulib} @code{quote}
and @code{quotearg} modules provide a reasonably straightforward way
support locale-specific quote characters, as well as taking care of
s/support/to support/
Paul Eggert [EMAIL PROTECTED] wrote:
...
How about the following (also untested) patch?
2005-06-17 Paul Eggert [EMAIL PROTECTED]
* xmalloc (HAVE_GNU_CALLOC): New macro.
(xcalloc): Omit needless tests if ! HAVE_GNU_CALLOC.
Looks fine to me.
Thanks!
Oskar Liljeblad [EMAIL PROTECTED] wrote:
What's the proper way to fix these warnings?
quotearg.c: In function `quotearg_n_options':
quotearg.c:586: warning: comparison is always false due to limited range of
data type
Paul, if you don't find a way to eliminate the warning by changing
Paul Eggert [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
Oskar Liljeblad [EMAIL PROTECTED] wrote:
What's the proper way to fix these warnings?
quotearg.c: In function `quotearg_n_options':
quotearg.c:586: warning: comparison is always false due to limited range of
data
Oskar Liljeblad [EMAIL PROTECTED] wrote:
On Wednesday, June 22, 2005 at 11:50, Jim Meyering wrote:
...
These days, I rarely use -W (and never use it with -Werror),
for precisely that reason.
I get that warning without both -W and -Wall, I think.
(gcc 3.3.6)
I've tried with the following
Oskar Liljeblad [EMAIL PROTECTED] wrote:
On Wednesday, June 22, 2005 at 13:47, Jim Meyering wrote:
I get that warning without both -W and -Wall, I think.
(gcc 3.3.6)
I've tried with the following versions of gcc on x86_64-unknown-linux-gnu:
gcc-3.3 (GCC) 3.3.6 (Debian 1:3.3.6-6)
gcc
Paul Eggert [EMAIL PROTECTED] wrote:
Oskar Liljeblad [EMAIL PROTECTED] wrote:
...
quotearg.c: In function `quotearg_n_options':
quotearg.c:586: warning: comparison is always false due to limited range of
data type
...
My own experience is that that particular warning is more trouble
than
Paul Eggert [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
With gcc-4.0 -O -Wall, I get these new warnings:
Odd; I don't get those warnings with gcc 4.0.0 -O -Wall:
$ gcc -DHAVE_CONFIG_H -I. -I.. -O -Wall -c mktime.c
$ gcc --version | sed 1q
gcc (GCC) 4.0.0
I'm using
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
Paul Eggert [EMAIL PROTECTED] wrote:
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
...
I assume that this was due to a warning from gcc -W about a missing
Simon Josefsson [EMAIL PROTECTED] wrote:
Paul Eggert [EMAIL PROTECTED] writes:
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
Simon Josefsson [EMAIL PROTECTED] wrote:
I'm using this module in all of my GNU packages. One complication
might be that it depends on VERSION being defined. Feedback
appreciated.
Looks useful, but sounds like a job better implemented
in a higher level language. But maybe you have
Simon Josefsson [EMAIL PROTECTED] wrote:
Paul Eggert [EMAIL PROTECTED] writes:
Simon Josefsson [EMAIL PROTECTED] writes:
/* Check version of libgcrypt. */
if (!gcry_check_version (GCRYPT_VERSION))
die (version mismatch\n);
Can't you use strverscmp for this? E.g.:
Simon Josefsson [EMAIL PROTECTED] wrote:
Ah, right. I accidentally installed the m4 file. Ok to install the
rest too?
Sure. It looks fine to me.
Thanks.
___
bug-gnulib mailing list
bug-gnulib@gnu.org
Paul Eggert [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
#define GL_CONCAT...
#define VERIFY(assertion) \
struct GL_CONCAT (compile_time_assert_, __LINE__) \
{ char a[(assertion) ? 1 : -1]; }
This trick won't work if VERIFY is used in two different files
I've just removed all tests for HAVE_FCNTL_H from coreutils.
It's been gone in at least one place since coreutils-5.0 (2004-04-02)
and no one has complained, so I think it's safe to say every system
we care about has fcntl.h, now.
If you know of a system (reasonable portability target)
that lacks
Jim Meyering [EMAIL PROTECTED] wrote:
I've just removed all tests for HAVE_FCNTL_H from coreutils.
It's been gone in at least one place since coreutils-5.0 (2004-04-02)
The same applies to HAVE_UNISTD_H and unistd.h,
but I haven't yet made the change in coreutils.
I'll do it over the weekend
false positives with FTS_NOSTAT|FTS_LOGICAL.
Here's a barely-tested fix (tested only with an instrumented chown-core.c
via `chown -RL' since I don't have the latest find sources here):
Barring negative feedback, I'll check it in to gnulib
in a day or two.
2005-08-09 Jim Meyering [EMAIL PROTECTED
James Youngman [EMAIL PROTECTED] wrote:
This patch resolves my problem; thanks. Might I suggest though that
you enhance the ChangeLog entry to describe the problem as well as the
solution?
This change requires some comment changes, too.
I'll do both.
Bruno Haible [EMAIL PROTECTED] wrote:
Jim Meyering wrote:
Note that POSIX *does* require a failed malloc call to set errno to
ENOMEM, albeit with CX shading (meaning IEEE Std 1003.1-2001).
http://www.opengroup.org/susv3xsh/malloc.html
Let's try not to let substandard systems dictate
I've just committed that patch.
Jim Meyering [EMAIL PROTECTED] wrote:
...
Thanks for reporting that.
With the following changes,
./gnulib-tool --test fts
once again passes.
2005-08-24 Jim Meyering [EMAIL PROTECTED]
* modules/fcntl-safer: New module.
* modules/fts (Depends
Today I tried to use `cp' to copy a file larger than 2GB and
was surprised to get a `File too large' error.
Here's the patch I've applied to both coreutils and gnulib:
2005-08-25 Jim Meyering [EMAIL PROTECTED]
* open-safer.c: Include config.h.
Otherwise, we'd lose LARGEFILE
Stepan Kasal [EMAIL PROTECTED] wrote:
could you please look at my patch submitted in
http://lists.gnu.org/archive/html/bug-gnulib/2005-07/msg00084.html
That looks fine. Thanks for doing that.
Please apply.
___
bug-gnulib mailing list
Yoann Vandoorselaere [EMAIL PROTECTED] wrote:
Hi Jim,
Would it be possible to change the pathmax license from GPL to LGPL ? I
would like to use the module from the prelude library, which require
external code to be LGPL.
Regards,
That's fine with me, and it's certainly small enough, but
Jim Meyering [EMAIL PROTECTED] wrote:
Paul Eggert [EMAIL PROTECTED] wrote:
It will take a while for this [gcc] fix to propagate, though. In the
Is there a patch yet to make gcc suppress that warning?
FYI, here is the warning again
[line 586 referred to the test in the expansion
[EMAIL PROTECTED] (Eric Blake) wrote:
The following patch was needed to make 'gnulib-tool --test fts' pass
again. Is there some way to improve new file creation to ensure that
all files are claimed by a module?
2005-08-31 Eric Blake [EMAIL PROTECTED]
* modules/unistd-safer (Files):
Paul Eggert [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
Is there a patch yet to make gcc suppress that warning?
Sorry, not yet. Other things are on my plate
- unsigned int n1 = n0 + 1;
+ /* FIXME: technically, the type of n1 should be `unsigned int
Paul Eggert [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
Is it really permitted to have sizeof (size_t) sizeof (unsigned int)?
...
The offending warning breaks coreutils' `make distcheck' rule.
Would it make sense to rewrite coreutils 'make distcheck' to filter
out
Paul Eggert [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
A week or so ago, I stumbled across one interface that was missing a
`const' attribute on a parameter, then dug up a few more. Paul, let me
know when you reach a point at which my checking this in won't interfere
Bruno Haible [EMAIL PROTECTED] wrote:
Hi Paul, Jim, Alexandre,
gnulib-tool now supports multiple gnulib directories with a single
configure.ac. Simon needs this in GnuTLS. I need this in libglocale.
But half of gnulib doesn't work with gnulib-tool.
Due to AC_LIBSOURCES.
Hi Bruno,
There is
Derek Price [EMAIL PROTECTED] wrote:
Would anyone object to a patch that caused canon-host to output warnings
via error (0, ...) when one of the functions it calls fails?
getaddrinfo returns errors differently than gethostbyname and
gethostbyaddr, making outputting a useful error message upon
Derek Price [EMAIL PROTECTED] wrote:
Hrm. A new enum parameter would mean duplicating a bunch of potential
POSIX error codes from the other three functions. How about if I leave
the enum parameter somewhat opaque and provide a canon_host_error
(perhaps strcherror is a better name) to
Derek Price [EMAIL PROTECTED] wrote:
Okay. Will do. Should I ignore single-threaded apps entirely, keep the
error data in a global to simplify for single-threaded apps on NULL, or
break the functions into canon_host, canon_host_r, strcherror,
strcherror_r?
I don't thinks it's worthwhile to
Derek Price [EMAIL PROTECTED] wrote:
Derek Price wrote:
Hrm. Why isn't canon-host dependant on getaddrinfo? It would
The alternative is that the ch_strerror_r function I've been working on
would need to handle ENOMEM too, which introduces a dependency on
strerror_r... I almost have the
Yoann Vandoorselaere [EMAIL PROTECTED] wrote:
On Wed, 2005-08-31 at 08:35 +0200, Jim Meyering wrote:
Yoann Vandoorselaere [EMAIL PROTECTED] wrote:
Hi Jim,
Would it be possible to change the pathmax license from GPL to LGPL ? I
would like to use the module from the prelude library, which
Derek Price [EMAIL PROTECTED] wrote:
I've installed the attached patch. It is almost identical to my
previous one, with a few extra portability and typo fixes.
2005-09-12 Derek Price [EMAIL PROTECTED]
* modules/canon-host: Add canon-host.h. Depend on getaddrinfo. Make
LGPL.
Derek Price [EMAIL PROTECTED] wrote:
Jim, all,
Is there a GNULIB standard for this yet? Paul Eggert just went through
my glob_.h and tweaked the cpp spacing in the other direction. I
assumed at the time this meant that double-include protection should be
ignored for the purposes of
Derek Price [EMAIL PROTECTED] wrote:
Jim Meyering wrote:
Personally, I've found it useful enough to have consistently cpp-indented
I like it too, but I was willing to go with the flow on GNULIB. :)
sources that I wrote cppi, and to use it in a commit-hook for the coreutils.
I don't know
the result of formatting (according to the
nstrftime format string, FMT) the time data, *TM, and the UTC
and NANOSECONDS values. */
size_t fprintftime (FILE *fp, char const *fmt, struct tm const *tm,
int utc, int nanoseconds);
2005-09-16 Jim Meyering [EMAIL PROTECTED
Hi Bruno,
Since unicode_to_mb is not declared in any other file
that I can see, nor is it used elsewhere in gnulib,
I suspect it really should have file scope.
Here's a patch:
Index: unicodeio.c
===
RCS file:
Bruno Haible [EMAIL PROTECTED] wrote:
Paul Eggert wrote:
The first step is to add a new module verify, which defines macros
verify(EXPR) and verify_expr(EXPR) that act like assert(EXPR) except
they check EXPR at compile-time, not at run-time. verify(EXPR) is for
declaration contexts, and
I've just discovered/fixed a build problem with the getaddrinfo module.
It didn't depend on the socklen module (for the declaration of socklen_t).
So I've merged these changes from coreutils:
2005-09-23 Jim Meyering [EMAIL PROTECTED]
* modules/getaddrinfo (Depends-on): Add socklen
Paul Eggert [EMAIL PROTECTED] wrote:
...
How about the following patch instead? I installed it in gnulib and
coreutils (though I suspect it may not be the last word, with all
these screwy compilers to test).
2005-09-23 Paul Eggert [EMAIL PROTECTED]
* verify.h (GL_CONCAT0,
Paul Eggert [EMAIL PROTECTED] wrote:
Bruno Haible [EMAIL PROTECTED] writes:
This is redundant. The module dependency from 'getaddrinfo' to 'socklen'
already implies that gl_SOCKLEN_T must be invoked from configure.ac,
directly or indirectly. No need to repeat the module dependencies in the
Bruno Haible [EMAIL PROTECTED] wrote:
Paul Eggert wrote:
I suspect it may not be the last word, with all
these screwy compilers to test).
Indeed, IRIX 6.5 cc gives warning: signed bitfield of length 1.
Changing the verify_type__ macro like this makes it work without warning.
# define
.
# define verify_type__(R) \
struct { int verify_error_if_negative_size__ : (R) ? 2 : -1; }
Or just make the bitfield use type `unsigned int'.
Then people won't wonder why we used 2 instead of 1,
and we won't have to worry about documenting it, either.
I checked this in:
2005-09-24 Jim
Simon Josefsson [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
I've just discovered/fixed a build problem with the getaddrinfo module.
It didn't depend on the socklen module (for the declaration of socklen_t).
So I've merged these changes from coreutils:
Hm. socklen_t
Paul Eggert [EMAIL PROTECTED] wrote:
I have a different idea: replace verify_expr(R) with a new macro
verify_true(R) that acts like verify_expr(R), but is an integer
constant expression that always yields true. The advantage of
verify_true(R) is that it can be used in contexts where
Paul Eggert [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
2005-09-27 Jim Meyering [EMAIL PROTECTED]
* intprops.h (signed_type_or_expr__): Define.
(INT_STRLEN_BOUND) [__GNUC__]: Use a slightly tighter bound
for unsigned types.
That looks good to me; thanks
Hi Simon,
I noticed that getaddrinfo.h guards the inclusion of sys/types.h
with an #ifdef HAVE_SYS_TYPES_H.
Do you know of a system that lacks sys/types.h?
I don't see any other uses of HAVE_SYS_TYPES_H in gnulib.
How about HAVE_SYS_SOCKET_H?
At least poll.c uses sys/socket.h without the
Simon Josefsson [EMAIL PROTECTED] wrote:
Let's not wait for glibc to install my patch... What do you think
about installing the following in gnulib now? It would sync gnulib
with my proposed libc-patch. It also fixes the sha1 module to be
standalone.
I like it. Thanks for the clean-up.
I
Simon Josefsson [EMAIL PROTECTED] wrote:
Ok to install?
Comments appreciated, of course.
Hi Simon,
In this function,
+rijndael_rc
+rijndaelMakeKey (rijndaelKeyInstance * key, rijndael_direction direction,
+int keyLen, char *keyMaterial)
the keyMaterial parameter should be
Simon Josefsson [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
Simon Josefsson [EMAIL PROTECTED] wrote:
Ok to install?
Comments appreciated, of course.
Hi Simon,
In this function,
+rijndael_rc
+rijndaelMakeKey (rijndaelKeyInstance * key, rijndael_direction direction
Simon Josefsson [EMAIL PROTECTED] wrote:
Revised patch.
Do those `U' suffixes serve any purpose,
given an array base type of uint32_t?
Index: lib/rijndael-alg-fst.c
...
+static const uint32_t Te0[256] = {
+ 0xc66363a5U, 0xf87c7c84U, 0xee99U, 0xf67b7b8dU,
+ 0xfff2f20dU, 0xd66b6bbdU,
Simon Josefsson [EMAIL PROTECTED] wrote:
The glibc maintainers didn't accept this patch, see:
http://sourceware.org/bugzilla/show_bug.cgi?id=1439
I can understand why Ulrich would not want such a patch.
It's probably hard to justify risking glibc stability for a relatively
large change that
Bruno Haible [EMAIL PROTECTED] wrote:
Simon Josefsson wrote:
you don't need it,
because the rules for struct layout in C guarantee that a structure field
is aligned to a multiple of the alignment of the previous field.
Are you saying that even if we don't change the type of buffer to
Paul Eggert [EMAIL PROTECTED] wrote:
...
Anyone who sets the system clock past 2038 and then runs a
gnulib-based program that they've compiled in
hamstrung-to-32-bit-time_t mode deserves whatever misbehavior they
provoke.
I suppose a clock-hardware problem could provoke this, so it might not
Simon Josefsson [EMAIL PROTECTED] wrote:
...
And it also assumes no holes in integer representations.
This is more portable:
verify (offsetof (struct S, member_m) % alignof (uint32_t) == 0);
where alignof is defined as with md5.c etc.
The verify module is GPL. If you re-license it, md4
Hi Paul,
What do you think of making gethrxtime fall back on gettime?
Currently, if it can't find a monotonic timer, it tries gettimeofday,
then resorts to using time. Those are also the last resorts of
gettime. The difference is that if gethrxtime used gettime,
it'd benefit by using nanotime
Paul Eggert [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
What do you think of making gethrxtime fall back on gettime?
Yes, that makes sense to me. I installed the patch below. This
also fixes the comments to match the code.
Looks fine.
Thanks!
While we're
[ I have to preface this by saying I'm not interested in the
attribute-related semantics of openat, but rather in the
fd-relative-open--related semantics. ]
Why do we need openat and related functions in the kernel?
Without openat-like functions[1], it is impossible to process
an
Paul Eggert [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
Assuming someone cares about the affected systems,
I'd be happy to let them do it.
But in the meantime, everyone else who wanted to run on mingw would be
left high and dry, as coreutils wouldn't build
Paul Eggert [EMAIL PROTECTED] wrote:
Eric Blake [EMAIL PROTECTED] writes:
Is there a preference for 'const char *' over 'char const *'?
I prefer putting type qualifiers like const after the types they
modify, as that's more consistent. For example, char * const * puts
As you've probably
Jim Meyering [EMAIL PROTECTED]
* mkdirat.c (mkdirat): New file and function.
* openat.h (mkdirat): Declare.
2005-11-30 Jim Meyering [EMAIL PROTECTED]
* openat.m4 (gl_FUNC_OPENAT): Require and compile mkdirat.c.
Here is the important part of the new file:
/* Solaris 10
Roland McGrath [EMAIL PROTECTED] wrote:
I think that the Solaris *at functions were really primarily intended for
use with O_XATTR to get at file attribute magic pseudo-directories rather
than to optimize use of normal directories and files. Probably mkdirat
doesn't make sense in Solaris
Roland McGrath [EMAIL PROTECTED] wrote:
So I guess the exec*at business would ultimately be more complicated,
with two file descriptor parameters: one identifying the working
directory, and another by which to interpret the first parameter
if it's a relative file name.
It seems adequate to
You can make any argp-using program infloop simply by running it
with --help and with something like ARGP_HELP_FMT=rmargin=a in the
environment. Or use a valid (but small) width: ARGP_HELP_FMT=rmargin=2
$ time ARGP_HELP_FMT=rmargin=2 tar --help /dev/null
ARGP_HELP_FMT=rmargin=2 tar --help
Sergey Poznyakoff [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] wrote:
You can make any argp-using program infloop simply by running it
with --help and with something like ARGP_HELP_FMT=rmargin=a in the
environment. Or use a valid (but small) width: ARGP_HELP_FMT=rmargin=2
Yes
.
With no need for memory allocation, that's one fewer way to fail.
* fprintftime.c, fprintftime.h: New files.
ChangeLog
2005-12-16 Jim Meyering [EMAIL PROTECTED]
* modules/fprintftime: New module.
* MODULES.html.sh (Date and time time.h): Add fprintftime.
Index: m4/ChangeLog
[EMAIL PROTECTED] (James Youngman) wrote:
On Fri, Dec 16, 2005 at 04:22:06PM +0100, Jim Meyering wrote:
I've just checked in the files that complete the
implementation of the new fprintftime module.
In coreutils, both date and du now use fprintftime.
Any plan to have 'ls' do so too
[EMAIL PROTECTED] (Eric Blake) wrote:
So experience in gnulib has shown that slightly different semantics,
with dir_name that always mallocs, and (when my patch from a
month ago is approved) base_name that mallocs and last_component
As far as I know, we're still waiting for confirmation from
a proposed
patch:
2005-12-14 Jim Meyering [EMAIL PROTECTED]
* xtime.h (xtime_nsec): Use `long int', not `int', to be
consistent with type of timespec.tv_nsec.
(xtime_make): Likewise for `ns' parameter.
Index: lib/xtime.h
Paul Eggert [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
[I sent this message a few weeks ago, but it was
mistakenly MIME-format=flowed, so not very readable]
Odd, I sent a reply (only to bug-gnulib), but I see it's not archived
so I guess it didn't get through the spam
Bruno Haible [EMAIL PROTECTED] wrote:
The reason is that m4/readutmp.m4 invokes gl_FUNC_FREE, but m4/free.m4 is not
part of this module or its dependencies.
Here is a fix. OK to commit?
Hi Bruno!
Thanks for working on this.
Adding the module dependency is fine.
However, I'm reluctant to
I discovered a long-standing bug in fts.c yesterday:
2006-01-11 Jim Meyering [EMAIL PROTECTED]
* fts.c (fts_stat): When following a symlink-to-directory,
don't necessarily interpret stat-fails+lstat-succeeds as indicating
a dangling symlink. That can also happen
Paul Eggert [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
If any of you know of a system with file name resolution code that
doesn't fail for a chain of 400 symlinks, or for which you get a
different diagnostic than `Too many levels of symbolic links' (ELOOP),
please
Simon Josefsson [EMAIL PROTECTED] wrote:
For some reason, mingw32 uses non-POSIX names for shutdown's
...
--- socket_.h 09 Jan 2006 17:13:09 +0100 1.1
+++ socket_.h 19 Jan 2006 14:39:07 +0100
@@ -34,4 +34,15 @@
# include ws2tcpip.h
#endif
+/* For shutdown(). */
+#if !defined(SHUT_RD)
Simon Josefsson [EMAIL PROTECTED] wrote:
Any objection to removing [useless parentheses]?
No, please install them.
Ok. I've checked that in.
I agree. I wish 'indent' could fix this
too. Maybe it can? Even if I agree many code writing ideas given
here, I forget them all the time.
I
-24 Jim Meyering [EMAIL PROTECTED]
* openat.m4 (gl_FUNC_OPENAT): Add AC_LIBSOURCES([intprops.h]).
Reported by Mark D. Baushke.
Index: m4/openat.m4
===
RCS file: /sources/gnulib/gnulib/m4/openat.m4,v
retrieving revision
Bruno Haible [EMAIL PROTECTED] wrote:
Building the module 'fts-lgpl' on Linux/glibc fails like this:
gcc -DHAVE_CONFIG_H -I. -I/packages/megatestdir/fts-lgpl/lib -I.. -g -O2
-c /packages/megatestdir/fts-lgpl/lib/fts.c
/packages/megatestdir/fts-lgpl/lib/fts.c:75:20: lstat.h: No such file
a little testing.
2006-02-02 Jim Meyering [EMAIL PROTECTED]
Eliminate the unwelcome (albeit unlikely) possibility of xmalloc
failure on deficient systems, and simplify gnulib lgpl dependencies.
* lstat.c (rpl_lstat): Rewrite to use stat() in place of the
xmalloc
Simon Josefsson [EMAIL PROTECTED] wrote:
I'm going through Coreutils GNUmakefile and Makefile.maint to identify
useful rules. Some question pop up:
1)
Is this rule generally safe? Does it assume GNU tar? Is there a real
problem solved by this, or is it just nice?
# Make tar archive
, you just create a new rule, and as long as its name starts
with `sc_' it'll be used:
2006-02-11 Jim Meyering [EMAIL PROTECTED]
* Makefile.maint (syntax-check-rules): Automatically derive this
list of sc_-prefixed rule names.
Index: Makefile.maint
Simon Josefsson [EMAIL PROTECTED] wrote:
I think CVS_LIST has some disadvantages:
* Unrelated to the core problem. The core problem is how to list all
C code or header files. Even if you use CVS_LIST, you'll have to
filter it further, excluding generated files the maintainer has no
Simon Josefsson [EMAIL PROTECTED] wrote:
# Make tar archive easier to reproduce.
export TAR_OPTIONS = --owner=0 --group=0 --numeric-owner
Those options help minimize unnecessary differences between tar archives.
...
Still, I think the TAR stuff is different. You can't set TAR_OPTIONS
in
Simon Josefsson [EMAIL PROTECTED] wrote:
I'm now using this (with a couple of modifications) in GNU SASL.
One thing that struck me as very useful, is the ability to invoke
tests without having to autoreconf + configure.
...
If I forget to run ./configure ..., I'd rather get a warning
than
Eric Blake [EMAIL PROTECTED] wrote:
Followup - with the earlier patch fixed, now AC_FUNC_STRERROR_R has a
warning, that was making the -Wall -Werror compilation think that
strerror_r returned int instead of char* on cygwin.
2006-02-16 Eric Blake [EMAIL PROTECTED]
*
Simon Josefsson [EMAIL PROTECTED] wrote:
Ok.
How about maint.mk and maint-cfg.mk?
Sounds good. Installed.
Auto-completing maint* is causing me problem already... while this is
very minor, it also occurred to me that cfg is rather incorrect.
maint-cfg.mk will likely contain a lot of local
Davide Angelocola [EMAIL PROTECTED] wrote:
hash.c with USE_OBSTACK fails to compile with gcc 3.3.4:
hash.c:38:16: #if with no expression
Define it to `1' if you want to enable that:
i.e., -DUSE_OBSTACK=1 on the command line
or
#define USE_OBSTACK 1
Ralf Wildenhues [EMAIL PROTECTED] wrote:
1) readline.m4 gives different results with cached reruns: for example,
on x86_64-unknown-linux-gnu:
./configure -C
- LIBREADLINE=-lreadline -lncurses
./config.status --recheck
- LIBREADLINE=-lreadline
This is because the commands
Ralf Wildenhues [EMAIL PROTECTED] wrote:
The following patch changes the last files over to the agreed-to style
for inclusion of `config.h'.
* lib/mkdtemp.c, lib/setenv.c, lib/unsetenv.c: Normalize
inclusion of `config.h'.
Thanks.
Applied.
Ralf Wildenhues [EMAIL PROTECTED] wrote:
The following patch changes the last files over to the agreed-to style
for inclusion of `config.h'.
* lib/mkdtemp.c, lib/setenv.c, lib/unsetenv.c: Normalize
inclusion of `config.h'.
Applied.
Hmm. Just noticed that those files are normally
[EMAIL PROTECTED] (Karl Berry) wrote:
Hmm. Just noticed that those files are normally mirrored from
gettext (see gnulib/config/srclist.txt).
Yes, although I haven't autoupdated yet because of those differences.
Bruno, would you accept Ralf's patch so we don't have to
that `#error' does not provoke failure everywhere, but don't
remember the offending compiler/system.
But there is even a patch to the contrary in gnulib, from coreutils:
| 2005-08-27 Jim Meyering [EMAIL PROTECTED]
|
| * md5.c: Use `#error' rather than a string literal to provoke
I wrote:
2006-03-10 Jim Meyering [EMAIL PROTECTED]
* src/remove.c (AD_pop_and_chdir): Fix a bug whereby a user with
write access to a directory being removed could cause the removal
of that directory to fail with an erroneous diagnostic about a
directory cycle
Simon Josefsson [EMAIL PROTECTED] wrote:
Installed.
2006-03-03 Simon Josefsson [EMAIL PROTECTED]
* build-aux/maint.mk: Add indent target.
--- maint.mk 15 Feb 2006 11:40:27 +0100 1.2
+++ maint.mk 03 Mar 2006 14:29:53 +0100
@@ -50,3 +50,8 @@
.PHONY: $(syntax-check-rules)
1 - 100 of 3388 matches
Mail list logo
