On 2011-09-22 I wrote:
> On MSVC 9, test-select does not link, because for the functions
> DispatchMessageA
> TranslateMessage
> PeekMessageA
> MsgWaitForMultipleObjects
> linking with -luser32 is necessary. On mingw, this linker option is apparently
> included by default.
The same holds f
On mingw, I'm seeing this compilation error:
$ make test-sys_select-c++.o
depbase=`echo test-sys_select-c++.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
g++-3 -mno-cygwin -DHAVE_CONFIG_H -I. -I.. -DGNULIB_STRICT_CHECKING=1
-DIN_GNULIB_TESTS=1 -I. -I. -I.. -I./.. -I../gllib -I./../gllib
-I/us
Eric Blake wrote:
> letting MSVC provide only an inline function will break the
> ability to pass around a function pointer for wmemchr.
No, it will only break the ability to compare such function pointers
with ==.
> I'm surprised that letting the inline function get by still passes the
> signa
Hi Eric,
> > Also, it can get a compilation error because it uses without
> > depending on the 'unistd' module.
>
> Shouldn't the fix for this to be adding a module dependency in
> modules/strsignal
The #include in lib/strsignal.c is only needed for NetBSD.
Here I've been thinking at Sam and
On 10/03/2011 05:31 PM, Bruno Haible wrote:
On MSVC 9, we get a compilation error in gnulib's
replacement, because the autoconf test has not found the wmemchr()
function - in fact, it's an inline function - and therefore
our wchar.h provides a substitute - which is in fact unnecessary.
Technica
On MSVC 9, we get a compilation error in gnulib's
replacement, because the autoconf test has not found the wmemchr()
function - in fact, it's an inline function - and therefore
our wchar.h provides a substitute - which is in fact unnecessary.
This fixes it. Likewise for wmemcmp, wmemcpy, wmemmove
On 10/03/2011 05:23 PM, Bruno Haible wrote:
On MSVC 9, strsignal.c gets many compilation errors,
because glthread/lock.h includes, which includes,
and includes. The two socket headers collide.
Also, it can get a compilation error because it uses without
depending on the 'unistd' module.
Shou
On MSVC 9, strsignal.c gets many compilation errors,
because glthread/lock.h includes , which includes ,
and includes . The two socket headers collide.
Also, it can get a compilation error because it uses without
depending on the 'unistd' module.
This fixes it.
2011-10-03 Bruno Haible
On Monday 03 October 2011 22:47:38 Bastien ROUCARIES wrote:
> On Mon, Oct 3, 2011 at 8:53 PM, Kamil Dudka wrote:
> > On Monday 03 October 2011 20:46:59 Bastien ROUCARIES wrote:
> >> Yes it is possible to mount file and it is call a bind mount. See man
> >> page of mount, and it is used in pratice
On Mon, Oct 3, 2011 at 8:53 PM, Kamil Dudka wrote:
> On Monday 03 October 2011 20:46:59 Bastien ROUCARIES wrote:
>> Yes it is possible to mount file and it is call a bind mount. See man page
>> of mount, and it is used in pratice essentially for /dev/null but it could
>> be used for any regular fi
On Monday 03 October 2011 20:46:59 Bastien ROUCARIES wrote:
> Yes it is possible to mount file and it is call a bind mount. See man page
> of mount, and it is used in pratice essentially for /dev/null but it could
> be used for any regular file
Thanks for the hint. I did not know this. Luckily,
Yes it is possible to mount file and it is call a bind mount. See man page
of mount, and it is used in pratice essentially for /dev/null but it could
be used for any regular file
Le 3 oct. 2011 19:29, "Kamil Dudka" a écrit :
On Monday 03 October 2011 18:25:10 Bruno Haible wrote:
> Kamil Dudka wr
On Monday 03 October 2011 20:13:53 Bruno Haible wrote:
> Kamil Dudka wrote:
> > > a) A non-symlink, non-directory. Here acl_extended_file_nofollow and
> > > acl_extended_file are equivalent.
> >
> > If I understand this, you expect non-directories cannot be mount points,
> > thus the call ca
Kamil Dudka wrote:
> > a) A non-symlink, non-directory. Here acl_extended_file_nofollow and
> > acl_extended_file are equivalent.
>
> If I understand this, you expect non-directories cannot be mount points, thus
> the call cannot trigger the mount, right?
That's what I was assuming, yes.
On Monday 03 October 2011 19:54:12 Kamil Dudka wrote:
> On Monday 03 October 2011 18:25:10 Bruno Haible wrote:
> > g) Must return 0.
> > h) Must return 0.
> > i) Must return 0.
>
> Does the above mean that you want to change the current behavior of ls -l?
Please ignore this. The above is co
On Monday 03 October 2011 18:25:10 Bruno Haible wrote:
> g) Must return 0.
> h) Must return 0.
> i) Must return 0.
Does the above mean that you want to change the current behavior of ls -l?
Kamil
On Monday 03 October 2011 18:25:10 Bruno Haible wrote:
> Kamil Dudka wrote:
> > > 2) see a test case added to gnulib or coreutils.
> >
> > A while ago, Jim wrote a test-case for coreutils that catches exactly the
> > bug that the original patch introduced.
>
> I'm asking for a test case also for
On Monday 03 October 2011 16:42:20 Jim Meyering wrote:
> Kamil,
> I've merged your two comment changes, kept my commit-log and ChangeLog
> and rebased past Bruno's latest change. This is what I expect to push:
>
> From 603b1e3b16894cac183952b0b0fe379749a3aebe Mon Sep 17 00:00:00 2001
> From: Kamil
Kamil Dudka wrote:
> > 2) see a test case added to gnulib or coreutils.
>
> A while ago, Jim wrote a test-case for coreutils that catches exactly the bug
> that the original patch introduced.
I'm asking for a test case also for the bug that the original patch fixed.
> > If you cannot come up
Kamil Dudka wrote:
> On Mon October 3 2011 15:02:20 Bruno Haible wrote:
>> The function name should explain the semantics of the function. The fact
>> that it's a wrapper around acl_extended_file is something one can see by
>> reading the code.
>>
>> Maybe call it acl_extended_file_optimized?
>
> S
On Mon October 3 2011 15:45:36 Bruno Haible wrote:
> In fact, the code already does this, at the beginning of the function
> file_has_acl. So in case c) the big compound statement is skipped, and the
> function immediately does a "return 0". The patch that you proposed on
> 2011-04-06 and committed
On Mon October 3 2011 15:45:36 Bruno Haible wrote:
> Kamil Dudka wrote:
> > The commit 95f7c57 introduced an unintended change in behavior of ls -L.
> > I am attaching a patch that restores the old behavior.
>
> This patch introduces an additional lstat() system call
Yes.
> , when it is not nece
On Mon October 3 2011 15:02:20 Bruno Haible wrote:
> The function name should explain the semantics of the function. The fact
> that it's a wrapper around acl_extended_file is something one can see by
> reading the code.
>
> Maybe call it acl_extended_file_optimized?
Sounds good.
> > +/* acl
On Mon October 3 2011 15:00:46 Jim Meyering wrote:
> Here's a version of your patch that I find more readable:
> - prefer if (CONDITION) over #if CONDITION, when possible
> - document the code more in comments, less in the commit log
> Is this ok with you?
Sure. Thanks for the improvements!
On Mon October 3 2011 13:51:39 Jim Meyering wrote:
> From: Jim Meyering
> Date: Mon, 3 Oct 2011 13:49:47 +0200
> Subject: [PATCH] tests: add a test to exercise today's ls-lL-vs-ACL bug
>
> * tests/ls/slink-acl: New file.
> * tests/Makefile.am (TESTS): Add it.
> * tests/init.cfg (require_setfacl_)
I found out how file_has_acl is meant to be called by looking at the coreutils
source code.
2011-10-03 Bruno Haible
acl: Fix specification.
* lib/file-has-acl.c (file_has_acl): Fix specification.
--- lib/file-has-acl.c.orig Mon Oct 3 15:47:44 2011
+++ lib/file-has-acl.c
Kamil Dudka wrote:
> The commit 95f7c57 introduced an unintended change in behavior of ls -L.
> I am attaching a patch that restores the old behavior.
This patch introduces an additional lstat() system call, when it is not
necessary.
Recall that when file_has_acl is called, it gets the result of
Kamil Dudka wrote:
> Thanks in advance for considering the patch!
> +#if (HAVE_ACL_EXTENDED_FILE) /* Linux */
Unnecessary parentheses.
> +acl_extended_file_wrap (char const *name)
The function name should explain the semantics of the function. The fact
that it's a wrapper around acl_extended_fi
Kamil Dudka wrote:
> The commit 95f7c57 introduced an unintended change in behavior of ls -L.
> I am attaching a patch that restores the old behavior. Thanks in advance
> for considering the patch!
Thanks again, Kamil,
Here's a version of your patch that I find more readable:
- prefer if (COND
Kamil Dudka wrote:
> On Mon October 3 2011 13:09:21 Jim Meyering wrote:
>> Kamil Dudka wrote:
>> > On Mon October 3 2011 12:45:01 Jim Meyering wrote:
>> >> Can you describe how to make "ls -L" misbehave without this patch?
>> >
>> > if you have a symlink to a file with ACL, 'ls -Ll' does not print
On Mon October 3 2011 13:09:21 Jim Meyering wrote:
> Kamil Dudka wrote:
> > On Mon October 3 2011 12:45:01 Jim Meyering wrote:
> >> Can you describe how to make "ls -L" misbehave without this patch?
> >
> > if you have a symlink to a file with ACL, 'ls -Ll' does not print the '+'
> > at end of the
Charles Wilson wrote:
> On 9/26/2011 6:00 PM, Bruno Haible wrote:
> > It is normal that --enable-relocatable has a runtime cost. Certainly when
> > you apply --enable-relocatable to small, fast programs like 'id' or 'pwd'
> > the runtime cost will be more perceivable than with programs which run
>
Kamil Dudka wrote:
> On Mon October 3 2011 12:45:01 Jim Meyering wrote:
>> Can you describe how to make "ls -L" misbehave without this patch?
>
> if you have a symlink to a file with ACL, 'ls -Ll' does not print the '+'
> at end of the column with permission bits.
Thanks. I expect to add somethin
Hi Jim,
On Mon October 3 2011 12:45:01 Jim Meyering wrote:
> Can you describe how to make "ls -L" misbehave without this patch?
if you have a symlink to a file with ACL, 'ls -Ll' does not print the '+'
at end of the column with permission bits.
> I.e., if there isn't already a test in coreutils
Kamil Dudka wrote:
> The commit 95f7c57 introduced an unintended change in behavior of ls -L.
> I am attaching a patch that restores the old behavior. Thanks in advance
> for considering the patch!
>
> Kamil
>
> From 75836c03cb21d616591b11164b626556d9f26152 Mon Sep 17 00:00:00 2001
> From: Kamil D
The commit 95f7c57 introduced an unintended change in behavior of ls -L.
I am attaching a patch that restores the old behavior. Thanks in advance
for considering the patch!
Kamil
From 75836c03cb21d616591b11164b626556d9f26152 Mon Sep 17 00:00:00 2001
From: Kamil Dudka
Date: Mon, 3 Oct 2011 12:17:
36 matches
Mail list logo
