On 06/02/2014 12:45 PM, Ben Walton wrote:
The value is only referenced if RENAME_DEST_EXISTS_BUG is set.
Otherwise, it's set but never used again. This patch addresses the
case where RENAME_DEST_EXISTS_BUG is unset. Thanks -Ben
Since that's not obvious, it might be a bit cleaner to have somet
The value is set in se
On Mon, Jun 2, 2014 at 8:31 PM, Pádraig Brady wrote:
> On 06/02/2014 08:13 PM, Ben Walton wrote:
>> * In the non-Win32 variant of rpl_rename, it is possible that
>> dst_exists may be set but not used. Mark it with the unused
>> attribute to avoid compiler warnings
On 06/02/2014 08:13 PM, Ben Walton wrote:
> * In the non-Win32 variant of rpl_rename, it is possible that
> dst_exists may be set but not used. Mark it with the unused
> attribute to avoid compiler warnings.
>
> Signed-off-by: Ben Walton
> ---
> lib/rename.c | 2 +-
> 1 file changed, 1
On Mon, Jun 2, 2014 at 3:02 PM, Paul Eggert wrote:
> Ben Walton wrote:
>>
>> With a new _GL_UNUSED_LABEL, which is cleaner than my patch, I'm less
>> inclined.
>
>
> Then please go with that. It's not a big deal either way.
Done. Updated patch sent.
Thanks
-Ben
--
-
On 06/02/2014 07:50 PM, Ben Walton wrote:
> * Avoid possible compiler warnings/errors by marking the out label
> as potentially unused.
>
> Signed-off-by: Ben Walton
> ---
> lib/rename.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/lib/rename.c b/lib/rename.
* In the non-Win32 variant of rpl_rename, it is possible that
dst_exists may be set but not used. Mark it with the unused
attribute to avoid compiler warnings.
Signed-off-by: Ben Walton
---
lib/rename.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/rename.c b/
* Avoid possible compiler warnings/errors by marking the out label
as potentially unused.
Signed-off-by: Ben Walton
---
lib/rename.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/lib/rename.c b/lib/rename.c
index 2116028..55130d8 100644
--- a/lib/rename.c
+++ b/lib
On 06/02/2014 11:12 AM, Gavin Smith wrote:
(i) posix_openpt isn't documented in the glibc manual (but I've raised
a bug for this), and (ii) posix_openpt has an ugly name.
I wouldn't worry about the lack of documentation; posix_openpt is not
going away any time soon. Admittedly the name is ugl
On Mon, Jun 2, 2014 at 4:47 PM, Paul Eggert wrote:
> Why not just use posix_openpt?
If the two functions are exactly the same (I think they are), this
would be acceptable. There are two weak reasons to use getpt instead:
(i) posix_openpt isn't documented in the glibc manual (but I've raised
a bug
Why not just use posix_openpt?
I was wondering what the chances would be of getting support for the
getpt function in gnulib? It's a GNU stdlib.h extension to get a file
descriptor for a master pseudo-terminal. As far as I can tell it does
something very similar to posix_openpt, and there is already a gnulib
posix_openpt module.
Ben Walton wrote:
Should I simply add a conditional
logic to detect Solaris (and later other platforms) that exhibit this
mismatch
That'd be OK, thanks. If someone wants to do something fancier that'd
be even better.
Ben Walton wrote:
With a new _GL_UNUSED_LABEL, which is cleaner than my patch, I'm less
inclined.
Then please go with that. It's not a big deal either way.
Ben Walton wrote:
The lib/file-has-acl.c:acl_ace_nontrivial code that returns 1 is:
Why is it returning 1, exactly? What are the value of access_masks[0,
1] and how do they compare to the masks, and what bits are set that
shouldn't be if we want the ACLs to be trivial?
On 06/01/2014 12:16 PM, Denis Laroche wrote:
> I'm not sure if the post should be sent to the autoconf mailing list
> instead. I see the following warnings from gl_EARLY when running
> autoconf (version 2.69):
The bug is on your end, not in gnulib.
> The version of gnulib is 0.1.147-b1b4ba. Look
On 06/01/2014 12:39 AM, Geoff wrote:
> I am (would be) _very_ happy - ecstatic even - about my present situation. My
> concern is one regarding certain memory leaks I found I could not avoid with
> regard to parent processes. I had hoped to limit the page tables accessed by
> these parent proces
Hi All,
I've hit a "bug" in the coreutils test suite when exercising acl code
from gnulib. I'm cross-posting to both lists, I hope that's ok.
(Please apply the cluebat gently if not...)
When running tests involving cp -a (in /tmp for this example), I see
errors like:
+ cp -a --parents d/a/b/c e
Hi All,
When building coreutils on solaris 10 x86 with warnings as errors, the
mountlist.c code using hasmntopt complains about passing a const char
to a function expecting char. Solaris defines hasmntopt as:
char *hasmntopt(struct mnttab *, char *);
While it's easy to patch around locally,
On Sun, Jun 1, 2014 at 11:47 PM, Paul Eggert wrote:
> Ben Walton wrote:
>>
>> WIth your suggested followup
>> (prerequisite), I think that it's a better solution.
>
>
> Better yet, how about putting the goto-containing code into a subsdiary
> static function that can return rather than goto? That
19 matches
Mail list logo
