On 09/28/2010 01:33 PM, Bruno Haible wrote:
Eric Blake wrote:
Hmm - this would be the first time that one of our replacement headers
#includes a non-replacement header
I agree that we shouldn't go this route. libunistring installs the gnulib-
created variants of stdint.h and stdbool.h in public locations (under different
names); I think some of Simon's packages do the same.
Thinking more _why_ should<stdlib.h> declare WIFEXITED etc. at all? Most
programs I've seen include<sys/wait.h> for this purpose. The answer is that
<stdlib.h> declares the system() function and WIFEXITED etc. are useful for
analyzing its return code.
So my proposal would be
- Introduce a new module 'system', that provides all a user needs for using
the system() function according to POSIX.
- Make dependencies system -> stdlib
system -> sys_wait
but not stdlib -> sys_wait.
- Change<stdlib.h> so that it #include<sys/wait.h> only when the 'system'
module has been requested.
Also seems like a reasonable solution to me.
New module 'system'.
* modules/system: New file.
* lib/stdlib.in.h: Include<sys/wait.h> only when the 'system' module
is present.
It doesn't hurt to unconditionally include <sys/wait.h> when WEXITSTATUS
is undefined; it's just that we can't guarantee that including
<sys/wait.h> will define WEXITSTATUS unless sys_wait is also in use
(which it will be if the system module is in use).
* m4/stdlib_h.m4 (gl_STDLIB_H_DEFAULTS): Initialize GNULIB_SYSTEM.
* modules/stdlib (Depends-on): Remove sys_wait.
(Makefile.am): Substitute GNULIB_SYSTEM.
* doc/posix-functions/system.texi: Mention the new module.
* doc/posix-headers/stdlib.texi: Likewise.
Reported by Sam Steingold<s...@gnu.org>.
Missing a change to tests/test-stdlib.c to not test the system()-related
macros unless the GNULIB_SYSTEM indicator is set.
+++ lib/stdlib.in.h Tue Sep 28 21:24:54 2010
@@ -39,7 +39,7 @@
#include<stddef.h>
/* MirBSD 10 defines WEXITSTATUS in<sys/wait.h>, not in<stdlib.h>. */
-#ifndef WEXITSTATUS
+#if @GNULIB_SYSTEM@&& !defined WEXITSTATUS
# include<sys/wait.h>
#endif
So I'm not convinced we need this hunk.
--
Eric Blake ebl...@redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
