Re: Ensuring that all the fields of struct predicate are initialized

[Collin Funk]

On 5/14/24 2:15 PM, James Youngman wrote:
> I should explain that recently I've been using other languages which make
> it possible to ensure at compile time that things are correctly initialised
> and consistently used, and to be direct about it, I miss these things in C.

Newer GCC versions have -fanalyzer and
-Wanalyzer-use-of-uninitialized-value which you might be interested
in. I pasted an example in bug-gnulib a few days ago [1].

Collin

[1] https://lists.gnu.org/archive/html/bug-gnulib/2024-05/msg00119.html

[bug #65792] Improve support for file birth time

[Collin Funk]

Follow-up Comment #1, bug #65792 (group findutils):

Perhaps it makes sense to add a function in Gnulib that allows fetching the
creation-time of a file?

On the BSDs you can use struct stat to get the birthtime [1].

Linux has statx as you mentioned [2].

Windows (not sure if Findutils supports it) through GetFileTime [3].

>From what I can tell AIX and Solaris don't have any way to get it.

Maybe a wrapper function around stat with an extra argument?

extern int stat_birthtime (const char *file, struct stat *st, struct timespec
*birthtime);

[2] https://man.freebsd.org/cgi/man.cgi?query=stat&sektion=2
[2] https://man7.org/linux/man-pages/man2/statx.2.html
[3]
https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfiletime


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #65792] Improve support for file birth time

[Collin Funk]

Follow-up Comment #3, bug #65792 (group findutils):


[comment #2 comment #2:]
> That already exists
(https://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/stat-time.h#n156) and
we're using it, as detailed in the first comment on this bug.  But there are
limitations in NetBSD's implementation which can give rise to incorrect
results.   See the link above for details.

Apologies, I probably explained it poorly. I'm aware of the stat-time module
and the BSD bug.

I was proposing an extended stat function in Gnulib that accepts an extra
'struct timespec *' argument.

That way any OS-specific details could be contained there, i.e. populating
'struct stat' from 'struct statx' on Linux.

The extra argument would contain the file creation time if supported by the
OS/file-system. Or else it's values will be set to -1 like
get_stat_birthtime().



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

Re: findutils 4.9.0: localeconv test failed on RISCV

[Collin Funk]

Hi,

Bernhard Voelker  writes:

> There's been some char-related changes in the related gnulib files between
> findutils 4.9.0 (2022) and the new 4.10.0.
> Would you please test if that problem still exists there?

No harm in trying this. However, I feel like this might be a platform
bug. Yuqi can you please tell me what operating system / libc
implementation you encountered this on?

As far as the behavior goes, the test is correct. From POSIX
Issue 7 [1]:

The members of the structure with type char * are pointers to
strings, any of which (except decimal_point) can point to "", to
indicate that the value is not available in the current locale or is
of zero length. The members with type char are non-negative numbers,
any of which can be {CHAR_MAX} to indicate that the value is not
available in the current locale.

Collin

[1] https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/

Re: test-framework-sh: Fix typo in function invocation (regression 2024-06-11).

[Collin Funk]

Bernhard Voelker  writes:

> Some of the files have to be physically copied into the version control like 
> COPYING
> and the 'fdl.texi', for other files we wanted to keep track of changes.
> This is the same in coreutils.
>
> Hence, the change in tests/init.sh will come with the next gnulib update
> which I'll eventually do in the next couple of days.

I see. That works perfectly. Thanks!

Collin

tests: adjust shell syntax that breaks AIX /bin/sh

[Collin Funk]

On AIX, /bin/sh causes a testsuite failure with an output like this:

Running 
/home/collinfunk/findutils-4.10.0.40-d4417/find/testsuite/find.gnu/execdir-multiple.exp
 ...
FAIL: execdir-multiple.new-O0, ./runme[6]: syntax error at line 7 : 
`newline or ;' unexpected
./runme[6]: syntax error at line 7 : `newline or ;' unexpected
./runme[6]: syntax error at line 7 : `newline or ;' unexpected
./runme[6]: syntax error at line 7 : `newline or ;' unexpected

Here is a small test program to show the issue:

$ cat test.sh 
#!/bin/sh
for arg;
do
  echo "$arg"
done
$ ./test.sh a b c
test.sh[3]: 0403-057 Syntax error at line 4 : `newline or ;' is not 
expected.

But, if we move the 'do' AIX /bin/sh no longer chokes:

$ cat test.sh 
#!/bin/sh
for arg; do
  echo "$arg"
 done
bash-5.2$ ./test.sh a b c
a
b
c

Normally I don't think this is worth fixing. But since it only affects
one test case I have attached a patch that fixes it.

Collin

>From c46de123b5e876ad7c50db113551f04d04faf5b1 Mon Sep 17 00:00:00 2001
From: Collin Funk 
Date: Sat, 25 Jan 2025 21:53:17 -0800
Subject: [PATCH] tests: adjust shell syntax that breaks AIX /bin/sh

* find/testsuite/find.gnu/execdir-multiple.exp: Move the 'do' of a for
loop to the same line so AIX doesn't fail.
---
 find/testsuite/find.gnu/execdir-multiple.exp | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/find/testsuite/find.gnu/execdir-multiple.exp b/find/testsuite/find.gnu/execdir-multiple.exp
index f292fffa..4ce23c3d 100644
--- a/find/testsuite/find.gnu/execdir-multiple.exp
+++ b/find/testsuite/find.gnu/execdir-multiple.exp
@@ -22,8 +22,7 @@ set -e
 here=`pwd`
 d=`basename $here`
 
-for arg;
-do
+for arg; do
   echo "$d" "$arg"
 done | LC_ALL=C sort
 }
-- 
2.48.1

Re: [PATCH] Update RE_SYNTAX_EMACS to include features used by GNU Emacs

[Collin Funk]

Bernhard Voelker  writes:

> 2. Commit (to be pushed) to gnulib - see attachment.
>
> Good to push?

That patch looks good, thanks. I confirmed that I receive the same
output when running './regexprops "Regular Expressions" generic'.

I'll send you a patch later to fix 'make syntax-check' after the Gnulib
update in Findutils.

Paul, just to confirm, the goal is to change RE_SYNTAX_EMACS in glibc? I
think that is what you meant here [1]:

>>   - Will they change the value of RE_SYNTAX_EMACS? Or can't they do this,
>> because that would break backward compatibility?
>
> The idea is to change the value of RE_SYNTAX_EMACS, yes.

I assume it will have to wait until the next release. But it feels a bit
strange to have RE_SYNTAX_EMACS not match what current Emacs does, and
not match the updated documentation.

Thanks,
Collin

[1] https://lists.gnu.org/archive/html/bug-gnulib/2025-04/msg00090.html