Eric Blake wrote:
> Jim Meyering meyering.net> writes:
>> I suspect that it'd be very hard to trigger these close failures,
>> but it's better to be safe.
>
> While we're visiting fts, how about this patch? POSIX 2008 is clear that
> opendir should use O_DIRECTORY, so opendirat should probably do
* Jim Meyering wrote on Tue, Sep 01, 2009 at 08:19:55AM CEST:
>
> I'd welcome patches to modernize the m4/*.m4 files under my care.
> Since I tend to use gnulib's files as models, it's worthwhile to
> update them to use macros that aren't listed as "obsolete".
OK, here we go. This patch is for m
Jim Meyering meyering.net> writes:
>
> I suspect that it'd be very hard to trigger these close failures,
> but it's better to be safe.
While we're visiting fts, how about this patch? POSIX 2008 is clear that
opendir should use O_DIRECTORY, so opendirat should probably do likewise. Do
we wan
Eric Blake byu.net> writes:
> > I think we need to implement opendir_safer, alongside all the other
> > *_safer modules. Otherwise, opendir can end up placing an open directory
> > fd in one of the standard slots, and end up interfering with the intent of
> > all the other *_safer wrappers.
>
>
Hello Bruno,
* Bruno Haible wrote on Tue, Sep 01, 2009 at 10:37:49AM CEST:
> I can see that in rare, rare cases, since MKDIR_P is a command, people
> may want to use different versions of it. But for things like @LIBINTL@
> and @LIBSOCKET@, it is still better to write them as @LIBINTL@, not
> $(L
Eric Blake byu.net> writes:
> +/* Return stat information about FD in STATBUF. Needed when
> + rpl_open() used a dummy file to work around an open() that can't
> + normally visit directories. */
> +#if REPLACE_OPEN_DIRECTORY
> +int
> +rpl_fstat (int fd, struct stat *statbuf)
> +{
> + if (0
FYI,
Here's a patch from Daniel P. Berrange to maint.mk.
Just pushed.
>From 1f6f04fa73397e0ed8de600aafdec45b976335a8 Mon Sep 17 00:00:00 2001
From: Daniel P. Berrange
Date: Tue, 1 Sep 2009 16:39:43 +0200
Subject: [PATCH] maint.mk: sort the list of syntax-check rules
* top/maint.mk (syntax-check-
Jim Meyering writes:
> So I'll let Simon push his patch.
Done! Thanks for discussion.
/Simon
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Ben Pfaff on 8/31/2009 6:56 AM:
> The reason that I'm submitting it is
> that I discovered this glibc bug myself, and it's been bothering
> me ever since that gnulib doesn't detect and work around it,
> because it seems very easy to trigge
On Tue, 2009-09-01 at 13:24 +0300, Sergey Poznyakoff wrote:
> Alan Hourihane ha escrit:
>
> > Yes, but I get this
> >
> > nm exclude.o | grep towlower
> > U _towlower
> >
> > And my libc doesn't define towlower() either.
>
> I see. Perhaps it is defined elsewhere? Could you pleas
On Tue, 2009-09-01 at 13:24 +0300, Sergey Poznyakoff wrote:
> Alan Hourihane ha escrit:
>
> > Yes, but I get this
> >
> > nm exclude.o | grep towlower
> > U _towlower
> >
> > And my libc doesn't define towlower() either.
>
> I see. Perhaps it is defined elsewhere? Could you pleas
Alan Hourihane ha escrit:
> Yes, but I get this
>
> nm exclude.o | grep towlower
> U _towlower
>
> And my libc doesn't define towlower() either.
I see. Perhaps it is defined elsewhere? Could you please check?
The gnulib's wchar.h does not provide a wrapper for it, unfortunately.
On Tue, 2009-09-01 at 13:10 +0300, Sergey Poznyakoff wrote:
> Alan Hourihane ha escrit:
>
> > exclude.c: In function 'string_hasher_ci':
> > exclude.c:167: warning: implicit declaration of function 'towlower'
> > exclude.c:167: warning: incompatible implicit declaration of built-in
> > function '
Alan Hourihane ha escrit:
> exclude.c: In function 'string_hasher_ci':
> exclude.c:167: warning: implicit declaration of function 'towlower'
> exclude.c:167: warning: incompatible implicit declaration of built-in
> function 'towlower'
These are warnings, not errors. What errors do you get? Pleas
On Tue, 2009-09-01 at 12:30 +0300, Sergey Poznyakoff wrote:
> Alan Hourihane ha escrit:
>
> > Not sure this is right, but it works
>
> Surely it is not right. And it does not work, either: it does
> not correctly lower the case of the input string.
>
> Have you tried the patch I sent?
Your
I suspect that it'd be very hard to trigger these close failures,
but it's better to be safe.
And along the same lines, since there are more way in which fts_close
can fail, encourage callers not to ignore its return value.
There were four offenders in coreutils, before today.
I chose not to make
On Tue, 2009-09-01 at 12:30 +0300, Sergey Poznyakoff wrote:
> Alan Hourihane ha escrit:
>
> > Not sure this is right, but it works
>
> Surely it is not right. And it does not work, either: it does
> not correctly lower the case of the input string.
>
> Have you tried the patch I sent?
Yike
Alan Hourihane ha escrit:
> Not sure this is right, but it works
Surely it is not right. And it does not work, either: it does
not correctly lower the case of the input string.
Have you tried the patch I sent?
Regards,
Sergey
On Thu, 2009-08-27 at 15:24 +0100, Alan Hourihane wrote:
> As the subject line says, and I end up with an unresolved symbol.
>
> Not sure what the right definition check to wrap that up in though.
Not sure this is right, but it works
Alan.
diff --git a/lib/exclude.c b/lib/exclude.c
index 32
Eric Blake wrote:
> > I usually modify CC instead. I never tried for gnulib, but it would
> > look like this:
> >
> > MINGW=$(cygpath -u '\mingw')
> > export PATH=$MINGW/bin:$PATH
> > ./configure --host=i586-pc-mingw32 --prefix=$MINGW \
> > CC="gcc -mno-cygwin" CXX="g++ -mno-cygw
Bruno Haible wrote:
> Jim Meyering wrote:
>> Consider consistency with automake-generated rules.
>> For example, I see these uses of $(MKDIR_P) in coreutils/lib/Makefile:
>> ...
>> I think anyone wanting to use some other MKDIR_P value
>> would be surprised (and report it as a bug) to have to
>> r
Bruno Haible wrote:
> Ralf Wildenhues wrote:
>> Still, the standards.texi authors found that additional flexibility so
>> useful that they explicitly document it as required for a set of tools
>> (node: Utilities in Makefiles).
>
> Citing it:
> Use the following @code{make} variables to run thos
Jim Meyering wrote:
> Consider consistency with automake-generated rules.
> For example, I see these uses of $(MKDIR_P) in coreutils/lib/Makefile:
> ...
> I think anyone wanting to use some other MKDIR_P value
> would be surprised (and report it as a bug) to have to
> resort to rerunning configure
Ralf Wildenhues wrote:
> Still, the standards.texi authors found that additional flexibility so
> useful that they explicitly document it as required for a set of tools
> (node: Utilities in Makefiles).
Citing it:
Use the following @code{make} variables to run those programs:
$(AR) $(BISON) $
24 matches
Mail list logo
