Hi Ben,
Ben Allen writes:
> Removing deprecated function hash_delete()
> ---
> lib/hash.c | 6 --
> lib/hash.h | 5 -
> 2 files changed, 11 deletions(-)
Thanks for the patch.
I recommended the same a while ago [1]. But the consensus was to wait
until a new version of GNU Patch has bee
Removing deprecated function hash_delete()
---
lib/hash.c | 6 --
lib/hash.h | 5 -
2 files changed, 11 deletions(-)
diff --git a/lib/hash.c b/lib/hash.c
index 2b123be754..b5bd8a32a0 100644
--- a/lib/hash.c
+++ b/lib/hash.c
@@ -1085,12 +1085,6 @@ hash_remove (Hash_table *table, const void
On 10/7/24 18:58, Bruno Haible wrote:
Either remove that #include (since fstype.c does not need it,
AFAICS),
or make it unconditional.
Good point, thanks.
Indeed. Thanks for the report. This patch fixes it:
Thanks!
Have a nice day,
Berny
Some C# implementations (from Microsoft) can be used on Cygwin. In this
environment, file names need to be translated from Cygwin syntax to Windows
syntax. These patches do so.
2024-10-07 Bruno Haible
csharpcomp: Improve Cygwin support.
* lib/csharpcomp.c: Include cygpath.h.
Hi Berny,
> While trying to update gnulib in findutils, I've been prompted by this new
> syntax-check failure:
>
>find/fstype.c:30:#if HAVE_MNTENT_H
>maint.mk: do not test the above HAVE__H symbol(s);
> with the corresponding gnulib module, they are always true
>make: *** [maint
On 8/19/24 5:23 PM, Bruno Haible wrote:
2024-08-19 Bruno Haible
...
hasmntopt: New module.
...
2024-08-19 Bruno Haible
mntent: New module.
While trying to update gnulib in findutils, I've been prompted by this new
syntax-check failure:
find/fstype.c:30:#if HAVE_M
> FAIL: test-file-has-acl.sh
> ==
>
> file_has_aclinfo failed for "tmpfile0"
> file_has_acl("tmpfile0") returned , expected no
> FAIL test-file-has-acl.sh (exit status: 1)
>
> FAIL: test-file-has-acl-1.sh
>
>
> file_has_aclinfo failed for "tmp
The recent changes in module file-has-acl can lead to extra system calls
executed on FreeBSD and Cygwin for the file_has_acl() function.
Namely, the caller of this function calls lstat(), and if the directory
entry is of some unusual type, the IFTODT macro returns DT_UNKNOWN, which
loses the infor
Paul Eggert wrote:
> + FLAGS should be a d_type value, optionally ORed with
> + AT_SYMLINK_FOLLOW; if the d_type value is not known,
This comment got me considering whether that's portable, and it is not:
AT_SYMLINK_FOLLOW DT_*
glibc/Linux0x400 0 .. 14
musl libc
