[PATCH] AC_FUNC_VFORK: check for Solaris 2.4 signal-handling bug

2012-09-16 Thread Paul Eggert
* NEWS:
* doc/autoconf.texi (Particular Functions): Document this.
* lib/autoconf/functions.m4 (_AC_FUNC_VFORK): Check for the bug.
---
 NEWS  |  7 ++-
 doc/autoconf.texi |  5 +
 lib/autoconf/functions.m4 | 24 
 3 files changed, 27 insertions(+), 9 deletions(-)

diff --git a/NEWS b/NEWS
index 0fda46e..7c1e77e 100644
--- a/NEWS
+++ b/NEWS
@@ -5,13 +5,18 @@ GNU Autoconf NEWS - User visible changes.
 ** The use of the long-deprecated name 'configure.in' for the autoconf
input file now elicits a warning in the 'obsolete' category.
 
-** MACROS
+** Macros
 
 - New macro AC_PROG_CC_C11.
 
 - AC_PROG_CC_STDC now prefers C11 if available, falling back on C99
   and then on C89 as before.
 
+- AC_FUNC_VFORK now checks for the signal-handling bug in Solaris 2.4 'vfork'.
+  Formerly, it ignored this bug, so that Emacs could use some tricky
+  code on that platform.  Solaris 2.4 has not been supported since
+  2003 and nowadays it's better to omit that old trick.
+
 * Noteworthy changes in release 2.69 (2012-04-24) [stable]
 
 ** Autoconf now requires perl 5.6 or better (but generated configure
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 7b8bfd5..611b675 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -4993,10 +4993,7 @@ If @file{vfork.h} is found, define @code{HAVE_VFORK_H}.  
If a working
 define @code{vfork} to be @code{fork} for backward compatibility with
 previous versions of @command{autoconf}.  This macro checks for several known
 errors in implementations of @code{vfork} and considers the system to not
-have a working @code{vfork} if it detects any of them.  It is not considered
-to be an implementation error if a child's invocation of @code{signal}
-modifies the parent's signal handler, since child processes rarely change
-their signal handlers.
+have a working @code{vfork} if it detects any of them.
 
 Since this macro defines @code{vfork} only for backward compatibility with
 previous versions of @command{autoconf} you're encouraged to define it
diff --git a/lib/autoconf/functions.m4 b/lib/autoconf/functions.m4
index 5987a0c..782393b 100644
--- a/lib/autoconf/functions.m4
+++ b/lib/autoconf/functions.m4
@@ -1894,10 +1894,18 @@ AC_DEFUN([_AC_FUNC_VFORK],
 [AC_CACHE_CHECK(for working vfork, ac_cv_func_vfork_works,
 [AC_RUN_IFELSE([AC_LANG_SOURCE([[/* Thanks to Paul Eggert for this test.  */
 ]AC_INCLUDES_DEFAULT[
+#include signal.h
 #include sys/wait.h
 #ifdef HAVE_VFORK_H
 # include vfork.h
 #endif
+
+static void
+do_nothing (int sig)
+{
+  (void) sig;
+}
+
 /* On some sparc systems, changes by the child to local and incoming
argument registers are propagated back to the parent.  The compiler
is told about this with #include vfork.h, but some compilers
@@ -1905,11 +1913,7 @@ AC_DEFUN([_AC_FUNC_VFORK],
static variable whose address is put into a register that is
clobbered by the vfork.  */
 static void
-#ifdef __cplusplus
 sparc_address_test (int arg)
-# else
-sparc_address_test (arg) int arg;
-#endif
 {
   static pid_t child;
   if (!child) {
@@ -1934,6 +1938,11 @@ main ()
 
   sparc_address_test (0);
 
+  /* On Solaris 2.4, changes by the child to the signal handler
+ also munge signal handlers in the parent.  To detect this,
+ start by putting the parent's handler in a known state.  */
+  signal (SIGTERM, SIG_DFL);
+
   child = vfork ();
 
   if (child == 0) {
@@ -1955,6 +1964,10 @@ main ()
|| p != p5 || p != p6 || p != p7)
   _exit(1);
 
+/* Alter the child's signal handler.  */
+if (signal (SIGTERM, do_nothing) != SIG_DFL)
+  _exit(1);
+
 /* On some systems (e.g. IRIX 3.3), vfork doesn't separate parent
from child file descriptors.  If the child closes a descriptor
before it execs or exits, this munges the parent's descriptor
@@ -1970,6 +1983,9 @@ main ()
 /* Was there some problem with vforking?  */
 child  0
 
+/* Did the child munge the parent's signal handler?  */
+|| signal (SIGTERM, SIG_DFL) != SIG_DFL
+
 /* Did the child fail?  (This shouldn't happen.)  */
 || status
 
-- 
1.7.11.4




Re: Why conditionally include config.h?

2012-09-16 Thread Kip Warner
On Sat, 2012-09-15 at 17:45 -0700, Russ Allbery wrote:
 I wouldn't go so far as to say that this is a general rule for everyone
 using Autoconf, but the way that I do it, which I believe is fairly
 common, is:
 
 * All regular source files (*.c files, for example) #include config.h as
   the first non-comment line in the file.
 
 * Internal (non-installed) header files #include config.h (generally
   after the multiple-inclusion header guard) if and only if they use
   Autoconf results directly.  I do not do this if the header file just
   uses data types that Autoconf may rename, only if the header file uses
   the regular HAVE_* symbols and the like.
 
   I do this only because I'm kind of obsessive about header files being
   self-contained and hence including everything they use.  Since every
   source file has #include config.h before anything else, including
   internal headers, there's really no need to include config.h in internal
   header files.  You may not want to follow my example here.  :)
 
 * Public, installed header files never #include config.h.  In general, I
   try to write all public interfaces so that they don't rely on anything
   outside of C89 or C99 (whatever I'm targetting) and therefore do not
   need any conditional results.
 
   Sometimes this isn't possible; when it isn't, I generate a separate
   publicly-installed header file that contains the definitions that I need
   but renamed so that they're within the namespace of my project (adding
   FOOBAR_ in front of all the HAVE_ symbols, for example).  I usually just
   roll this myself, but there are various macros to do this in, for
   example, the Autoconf Archive if you have this problem.  I then include
   that header file in other publicly-installed header files.
 
 Packages that violate the latter principal are extremely annoying.  Note
 that, because of the various PACKAGE_* defines, any Autoconf-generated
 config.h is basically guaranteed to always conflict with any config.h from
 another package, so this isn't something you can ever get away with.
 
 For example, when developing Apache modules, I have to generate a
 separate, stripped mod-config.h file in Autoconf to use with the module
 source files, since they have to include Apache header files as well and
 the Apache header files include an Autoconf-generated config.h file with
 no namespacing.  This is all very awkward and annoying, so please don't do
 that.  :)  (Other common culprits for this are the headers generated by
 scripting languages for their dynamically-loaded extension mechanism.)

Hey Russ. I just wanted to say thank you for helping to create some good
habits as I become more experienced with the autotools. The advice you
gave makes sense, although, today at least, I haven't any need for
public system headers (yet). But should I ever have a need for creating
them, I'll be sure to pay heed to your advice.

-- 
Kip Warner -- Software Engineer
OpenPGP encrypted/signed mail preferred
http://www.thevertigo.com


signature.asc
Description: This is a digitally signed message part
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf