Re: [PATCH] findprog: Support searching in a specified path string
Hi Paul,
> find_prog_in_path() always uses the PATH value in the current
> environment. It can be very useful to search for programs on
> a path without having to modify the environment first.
>
> Provide find_in_path_str() which takes a path string to search.
> If the path passed in is NULL, fall back to searching in the
> environment's PATH value.
I have nothing against extending the 'findprog' module in principle.
But the interface that you propose looks odd to me:
* Why one function that always uses $PATH and one function that
uses a given set of directories _or_ $PATH?
Why not simpler: one function that always uses $PATH and one
function that uses a given set of directories?
* For the function that uses a given set of directories, isn't
it easier for the caller to provide a NULL-terminated array
of directories, rather than to glue them together with a
platform-dependent separator (':' or ';')?
Because of this oddity, I have to ask: What is the use-case that
you have in mind? The use-case of the existing find_in_path function
is when a program wants to optimize multiple invocations (spawn/exec)
of one given program. What's yours?
Bruno
Re: [PATCH] findprog: Support searching in a specified path string
On Sat, 2019-09-07 at 12:42 +0200, Bruno Haible wrote:
> Hi Paul,
> > find_prog_in_path() always uses the PATH value in the current
> > environment. It can be very useful to search for programs on
> > a path without having to modify the environment first.
> >
> > Provide find_in_path_str() which takes a path string to search.
> > If the path passed in is NULL, fall back to searching in the
> > environment's PATH value.
>
> I have nothing against extending the 'findprog' module in principle.
>
> But the interface that you propose looks odd to me:
>
> * Why one function that always uses $PATH and one function that
> uses a given set of directories _or_ $PATH?
> Why not simpler: one function that always uses $PATH and one
> function that uses a given set of directories?
It was simpler to implement that way: less duplication of code between
the two implementations, albeit only by a few lines. Also it can be
handy for the user; they can use something like:
prog = find_in_path_str ("myprog", lookup_path ());
and if lookup_path() returns NULL it defaults to the environment PATH,
rather than having to do something like:
const char *path = lookup_path ();
if (path)
prog = find_in_path_str ("myprog", path);
else
prog = find_in_path ("myprog");
Of course it does mean you can't avoid looking in the user's
environment, if you wanted to, so that's a downside.
I don't have a strong preference myself.
> * For the function that uses a given set of directories, isn't
> it easier for the caller to provide a NULL-terminated array
> of directories, rather than to glue them together with a
> platform-dependent separator (':' or ';')?
Because that's not my use-case :). I already have a PATH string, it's
just not in my current environment. I don't want to have to break it
up myself; in fact if it was already broken up it would be
straightforward for me to use it directly without importing findprog.
See below.
> Because of this oddity, I have to ask: What is the use-case that
> you have in mind? The use-case of the existing find_in_path function
> is when a program wants to optimize multiple invocations (spawn/exec)
> of one given program. What's yours?
I'm addressing https://savannah.gnu.org/bugs/?56834
I want to invoke a child process, and I need the program I'm going to
invoke to be searched for in a PATH which is (potentially) different
than the PATH which is active in the parent.
When you use execlp(), you can just assign the child's environment
before you invoke the exec. Since you've already forked you're not
modifying the parent's environment.
However, with posix_spawnp() that doesn't work: the path search is done
on the _parent's_ PATH environment value not the one passed in to
posix_spawnp(). I don't want that, I need the search done in the
child's environment. I can't decide if this behavior by posix_spawnp()
is correct or not, and the POSIX spec isn't clear, but it's how it
works (at least on GNU/Linux).
At the same time, I don't want to be running putenv() to set then
reset the PATH environment variable in the parent every time I invoke
a command.
So what I want to do is run find_in_path_str() passing in the PATH from
the child's environment then pass the result to posix_spawn.
I suppose an even simpler interface, for me, would be something like:
find_in_path_envp (const char *prog, const char **envp);
where it would look up PATH in the environment passed in, so I don't
have to do the lookup of PATH, and use that instead of getenv(). But I
don't know if that's as generally useful an interface.
RE: test-symlink fails on "lustre" file system
Bruno,
Thank you for the patch. I have made the fix in my versions of:
sed-4.7 sed-4.7/gnulib-tests/test-symlink.h
m4-1.4.18 m4-1.4.18/tests/test-symlink.h
gettext-0.20.1
gettext-0.20.1/gettext-tools/gnulib-tests/test-symlink.h
since the same test failure occurs in these three packages. I will rerun my
build of GCC 9.2.0 with its many prerequisites packages (for all of which I
do "make check") and see what the results are.
It is great to clear up these test failures for Linux systems using the
Lustre file system.
Tom Oppe
-Original Message-
From: Bruno Haible [mailto:br...@clisp.org]
Sent: Friday, September 6, 2019 6:18 PM
To: bug-gnulib@gnu.org; Oppe, Thomas C ERDC-RDE-ITL-MS Contractor
Cc: 37...@debbugs.gnu.org; Assaf Gordon
Subject: Re: test-symlink fails on "lustre" file system
Thomas Oppe wrote:
> INSERTED errno=2
> test-symlink.h:71: assertion 'errno == EEXIST || errno == EINVAL'
> failed FAIL test-symlink (exit status: 134)
Thanks. I'm pushing this patch; it will fix the failure in this place.
2019-09-06 Bruno Haible
symlink tests: Avoid test failure on Linux with Lustre file system.
Reported by Thomas C Oppe
at
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37312Blocked>.
* tests/test-symlink.h (test_symlink): Accept errno value ENOENT.
diff --git a/tests/test-symlink.h b/tests/test-symlink.h index
c556347..8fd55c0 100644
--- a/tests/test-symlink.h
+++ b/tests/test-symlink.h
@@ -67,7 +67,8 @@ test_symlink (int (*func) (char const *, char const *),
bool print)
ASSERT (errno == EEXIST);
errno = 0;
ASSERT (func ("nowhere", BASE "dir/") == -1);
- ASSERT (errno == EEXIST || errno == EINVAL);
+ ASSERT (errno == EEXIST || errno == EINVAL
+ || errno == ENOENT /* Lustre FS on Linux */);
ASSERT (close (creat (BASE "file", 0600)) == 0);
errno = 0;
ASSERT (func ("nowhere", BASE "file") == -1);
smime.p7s
Description: S/MIME cryptographic signature
doc: update for glibc 2.30
After the big doc update from 2019-06-10, I don't want the gnulib documentation
again lag behind glibc by 5 years.
2019-09-07 Bruno Haible
doc: Update for glibc 2.30.
* doc/glibc-functions/gettid.texi: New file.
* doc/glibc-functions/pthread_cond_clockwait.texi: New file.
* doc/glibc-functions/pthread_mutex_clocklock.texi: New file.
* doc/glibc-functions/pthread_rwlock_clockrdlock.texi: New file.
* doc/glibc-functions/pthread_rwlock_clockwrlock.texi: New file.
* doc/glibc-functions/sem_clockwait.texi: New file.
* doc/glibc-functions/tgkill.texi: New file.
* doc/glibc-functions/twalk_r.texi: New file.
* doc/gnulib.texi: Include them.
(Glibc semaphore.h): New section.
* doc/pastposix-functions/h_errno.texi: Update.
* doc/posix-functions/*.texi: Likewise.
diff --git a/doc/glibc-functions/gettid.texi b/doc/glibc-functions/gettid.texi
new file mode 100644
index 000..dae3848
--- /dev/null
+++ b/doc/glibc-functions/gettid.texi
@@ -0,0 +1,30 @@
+@node gettid
+@subsection @code{gettid}
+@findex gettid
+
+Documentation:
+@itemize
+@item
+@ifinfo
+@ref{Process Identification,,Process Identification,libc},
+@end ifinfo
+@ifnotinfo
+@url{https://www.gnu.org/software/libc/manual/html_node/Process-Identification.html},
+@end ifnotinfo
+@item
+@uref{https://www.kernel.org/doc/man-pages/online/pages/man2/gettid.2.html,,man
gettid}.
+@end itemize
+
+Gnulib module: ---
+
+Portability problems fixed by Gnulib:
+@itemize
+@end itemize
+
+Portability problems not fixed by Gnulib:
+@itemize
+@item
+This function exists only on Linux and is therefore
+missing on most non-glibc platforms:
+Mac OS X 10.5, FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, Minix 3.1.8, AIX 5.1,
HP-UX 11, IRIX 6.5, Solaris 11.4, Cygwin, mingw, MSVC 14.
+@end itemize
diff --git a/doc/glibc-functions/pthread_cond_clockwait.texi
b/doc/glibc-functions/pthread_cond_clockwait.texi
new file mode 100644
index 000..916f2eb
--- /dev/null
+++ b/doc/glibc-functions/pthread_cond_clockwait.texi
@@ -0,0 +1,27 @@
+@node pthread_cond_clockwait
+@subsection @code{pthread_cond_clockwait}
+@findex pthread_cond_clockwait
+
+Documentation:
+@itemize
+@item
+@ifinfo
+@ref{Non-POSIX Extensions,,Non-POSIX Extensions,libc},
+@end ifinfo
+@ifnotinfo
+@url{https://www.gnu.org/software/libc/manual/html_node/Non_002dPOSIX-Extensions.html},
+@end ifnotinfo
+@end itemize
+
+Gnulib module: ---
+
+Portability problems fixed by Gnulib:
+@itemize
+@end itemize
+
+Portability problems not fixed by Gnulib:
+@itemize
+@item
+This function is missing on all non-glibc platforms:
+Mac OS X 10.5, FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, Minix 3.1.8, AIX 5.1,
HP-UX 11, IRIX 6.5, Solaris 11.4, Cygwin, mingw, MSVC 14, Android 9.0.
+@end itemize
diff --git a/doc/glibc-functions/pthread_mutex_clocklock.texi
b/doc/glibc-functions/pthread_mutex_clocklock.texi
new file mode 100644
index 000..7f3f5d2
--- /dev/null
+++ b/doc/glibc-functions/pthread_mutex_clocklock.texi
@@ -0,0 +1,18 @@
+@node pthread_mutex_clocklock
+@subsection @code{pthread_mutex_clocklock}
+@findex pthread_mutex_clocklock
+
+Documentation: ---
+
+Gnulib module: ---
+
+Portability problems fixed by Gnulib:
+@itemize
+@end itemize
+
+Portability problems not fixed by Gnulib:
+@itemize
+@item
+This function is missing on all non-glibc platforms:
+Mac OS X 10.5, FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, Minix 3.1.8, AIX 5.1,
HP-UX 11, IRIX 6.5, Solaris 11.4, Cygwin, mingw, MSVC 14, Android 9.0.
+@end itemize
diff --git a/doc/glibc-functions/pthread_rwlock_clockrdlock.texi
b/doc/glibc-functions/pthread_rwlock_clockrdlock.texi
new file mode 100644
index 000..5e034c5
--- /dev/null
+++ b/doc/glibc-functions/pthread_rwlock_clockrdlock.texi
@@ -0,0 +1,27 @@
+@node pthread_rwlock_clockrdlock
+@subsection @code{pthread_rwlock_clockrdlock}
+@findex pthread_rwlock_clockrdlock
+
+Documentation:
+@itemize
+@item
+@ifinfo
+@ref{Non-POSIX Extensions,,Non-POSIX Extensions,libc},
+@end ifinfo
+@ifnotinfo
+@url{https://www.gnu.org/software/libc/manual/html_node/Non_002dPOSIX-Extensions.html},
+@end ifnotinfo
+@end itemize
+
+Gnulib module: ---
+
+Portability problems fixed by Gnulib:
+@itemize
+@end itemize
+
+Portability problems not fixed by Gnulib:
+@itemize
+@item
+This function is missing on all non-glibc platforms:
+Mac OS X 10.5, FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, Minix 3.1.8, AIX 5.1,
HP-UX 11, IRIX 6.5, Solaris 11.4, Cygwin, mingw, MSVC 14, Android 9.0.
+@end itemize
diff --git a/doc/glibc-functions/pthread_rwlock_clockwrlock.texi
b/doc/glibc-functions/pthread_rwlock_clockwrlock.texi
new file mode 100644
index 000..117fb15
--- /dev/null
+++ b/doc/glibc-functions/pthread_rwlock_clockwrlock.texi
@@ -0,0 +1,27 @@
+@node pthread_rwlock_clockwrlock
+@subsection @code{pthread_rwlock_clockwrlock}
+@findex pthread_rwlock_clockwrlock
+
+Documentation:
+@itemize
+@item
+@ifinfo
+@ref{Non-POSIX Extensions,,Non-POSIX Extensions,libc},
Re: bitset: check memory allocation
Thanks, and your changes all look good to me; please install when you have the time. We can worry about the other issues later (if ever...).
[PATCH] scratch_buffer: sync from glibc
* config/srclist.txt: Add the scratch_buffer source
code from glibc, since these should be in sync.
Autoupdate.
---
ChangeLog | 7 +++
config/srclist.txt| 4
lib/malloc/scratch_buffer.h | 6 +++---
lib/malloc/scratch_buffer_grow_preserve.c | 4 ++--
lib/timegm.c | 2 +-
5 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 4e009db52..28a6b264b 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2019-09-07 Paul Eggert
+
+ scratch_buffer: sync from glibc
+ * config/srclist.txt: Add the scratch_buffer source
+ code from glibc, since these should be in sync.
+ Autoupdate.
+
2019-09-07 Bruno Haible
doc: Update for glibc 2.30.
diff --git a/config/srclist.txt b/config/srclist.txt
index 6d37729ce..4a3a5a7af 100644
--- a/config/srclist.txt
+++ b/config/srclist.txt
@@ -46,6 +46,10 @@ $GNUORG Copyright/request-assign.future
doc/Copyright
$GNUORG Copyright/request-assign.program doc/Copyright
$GNUORG Copyright/request-disclaim.changes doc/Copyright
+$LIBCSRC include/scratch_buffer.h lib/malloc
+$LIBCSRC malloc/scratch_buffer_grow.c lib/malloc
+$LIBCSRC malloc/scratch_buffer_grow_preserve.c lib/malloc
+$LIBCSRC malloc/scratch_buffer_set_array_size.clib/malloc
# Temporarily newer in Gnulib than in glibc.
#$LIBCSRC include/intprops.h lib
$LIBCSRC posix/regcomp.c lib
diff --git a/lib/malloc/scratch_buffer.h b/lib/malloc/scratch_buffer.h
index f83e1004b..0482773ac 100644
--- a/lib/malloc/scratch_buffer.h
+++ b/lib/malloc/scratch_buffer.h
@@ -66,7 +66,7 @@
struct scratch_buffer {
void *data;/* Pointer to the beginning of the scratch area. */
size_t length; /* Allocated space at the data pointer, in bytes. */
- max_align_t __space[(1023 + sizeof (max_align_t)) / sizeof (max_align_t)];
+ union { max_align_t __align; char __c[1024]; } __space;
};
/* Initializes *BUFFER so that BUFFER->data points to BUFFER->__space
@@ -74,7 +74,7 @@ struct scratch_buffer {
static inline void
scratch_buffer_init (struct scratch_buffer *buffer)
{
- buffer->data = buffer->__space;
+ buffer->data = buffer->__space.__c;
buffer->length = sizeof (buffer->__space);
}
@@ -82,7 +82,7 @@ scratch_buffer_init (struct scratch_buffer *buffer)
static inline void
scratch_buffer_free (struct scratch_buffer *buffer)
{
- if (buffer->data != buffer->__space)
+ if (buffer->data != buffer->__space.__c)
free (buffer->data);
}
diff --git a/lib/malloc/scratch_buffer_grow_preserve.c
b/lib/malloc/scratch_buffer_grow_preserve.c
index c3c6de18f..62fcc656b 100644
--- a/lib/malloc/scratch_buffer_grow_preserve.c
+++ b/lib/malloc/scratch_buffer_grow_preserve.c
@@ -30,14 +30,14 @@ __libc_scratch_buffer_grow_preserve (struct scratch_buffer
*buffer)
size_t new_length = 2 * buffer->length;
void *new_ptr;
- if (buffer->data == buffer->__space)
+ if (buffer->data == buffer->__space.__c)
{
/* Move buffer to the heap. No overflow is possible because
buffer->length describes a small buffer on the stack. */
new_ptr = malloc (new_length);
if (new_ptr == NULL)
return false;
- memcpy (new_ptr, buffer->__space, buffer->length);
+ memcpy (new_ptr, buffer->__space.__c, buffer->length);
}
else
{
diff --git a/lib/timegm.c b/lib/timegm.c
index bae0ceee5..00854c796 100644
--- a/lib/timegm.c
+++ b/lib/timegm.c
@@ -15,7 +15,7 @@
You should have received a copy of the GNU Lesser General Public
License along with the GNU C Library; if not, see
-
Re: bitset: check memory allocation
> Le 8 sept. 2019 à 03:17, Paul Eggert a écrit : > > Thanks, and your changes all look good to me; please install when you have > the time. We can worry about the other issues later (if ever...). Installed, thanks!
