Re: AC_TYPE_SIGNAL obsolete?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Bob Friesenhahn on 6/7/2008 11:43 AM:
|> Again, obsoleting a macro does not mean that existing code that relied on
|> the macro will break.  As long as you don't delete AC_TYPE_SIGNAL from
|> your configure.ac, your project will not be impacted (other than the fact
|> that if you run 'autoconf -Wall' you will get a new warning, mentioning
|> that the macro is obsolete when porting to modern targets).
|
| Since modern OS targets should all be compliant to the current Open
| Group specifications it seems that almost all of Autoconf related to
| OS-related porting must be obsolete!

You're twisting my words - I never claimed that obsolete autoconf tests
should not be used when specifically targetting older systems, nor that
all current porting targets are identical.  A target can be a modern
porting target without being modern in compliance; and not every OS out
there claims Open Group (SUSv3 and/or POSIX compliance).  In particular,
mingw qualifies as a modern OS target supported by autoconf, and it is
_nowhere_ near complaint.  Autoconf will have a place in detecting
software portability for some time to come.

At any rate, based on your confirmation that currently active porting
targets (whether or not they are modern in terms of hardware or standards
compliance) all use C89 semantics (after all, it's been 19 years since
signal was required to return void), I'm committing this:

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@xxxxxxx
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEUEARECAAYFAkhNIZcACgkQ84KuGfSFAYD9SACYnleQ+9rMdp9NkEt5byeRy2+f
OACfSxQ3wR7LVuvnR7+sQ0+pfG5EZ7o=
=S0mS
-----END PGP SIGNATURE-----
>From 7bedbd5be1009092bc211f50b3f4108b99f9334c Mon Sep 17 00:00:00 2001
From: Eric Blake <ebb9@xxxxxxx>
Date: Mon, 9 Jun 2008 06:25:35 -0600
Subject: [PATCH] Mark AC_TYPE_SIGNAL as obsolete.

* lib/autoconf/types.m4 (AC_TYPE_SIGNAL): Switch to AU_DEFUN.
* doc/autoconf.texi (Function Portability): Update documentation.
(Particular Types): Move AC_TYPE_SIGNAL...
(Obsolete Macros): ...here, and mention why.

Signed-off-by: Eric Blake <ebb9@xxxxxxx>
---
 ChangeLog             |    6 +++++
 doc/autoconf.texi     |   59 ++++++++++++++++++++++++++++--------------------
 lib/autoconf/types.m4 |   13 ++++++----
 3 files changed, 48 insertions(+), 30 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 85cc8cd..8288f12 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,11 @@
 2008-06-09  Eric Blake  <ebb9@xxxxxxx>
 
+	Mark AC_TYPE_SIGNAL as obsolete.
+	* lib/autoconf/types.m4 (AC_TYPE_SIGNAL): Switch to AU_DEFUN.
+	* doc/autoconf.texi (Function Portability): Update documentation.
+	(Particular Types): Move AC_TYPE_SIGNAL...
+	(Obsolete Macros): ...here, and mention why.
+
 	Allow lib64 as a default X library location.
 	* lib/autoconf/libs.m4 (_AC_PATH_X_XMKMF): Add lib64.
 	* NEWS: Mention the change.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index cef2d3b..43a84bc 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -4352,6 +4352,7 @@ NextStep).
 @item @code{signal} handler
 @c @fuindex signal
 @prindex @code{signal}
+@prindex @code{sigaction}
 Normally @code{signal} takes a handler function with a return type of
 @code{void}, but some old systems required @code{int} instead.  Any
 actual @code{int} value returned is not used; this is only a
@@ -4359,8 +4360,12 @@ difference in the function prototype demanded.
 
 All systems we know of in current use return @code{void}.  The
 @code{int} was to support K&R C, where of course @code{void} is not
-available.  @code{AC_TYPE_SIGNAL} (@pxref{Particular Types}) can be
-used to establish the correct type in all cases.
+available.  The obsolete macro @code{AC_TYPE_SIGNAL}
+(@pxref{AC_TYPE_SIGNAL}) can be used to establish the correct type in
+all cases.
+
+In most cases, it is more robust to use @code{sigaction} when it is
+available, rather than @code{signal}.
 
 @item @code{snprintf}
 @c @fuindex snprintf
@@ -6222,28 +6227,6 @@ Define @code{pid_t} to a suitable type, if standard headers do not
 define it.
 @end defmac
 
-@anchor{AC_TYPE_SIGNAL}
-@defmac AC_TYPE_SIGNAL
-@acindex{TYPE_SIGNAL}
-@cvindex RETSIGTYPE
-@hdrindex{signal.h}
-If @file{signal.h} declares @code{signal} as returning a pointer to a
-function returning @code{void}, define @code{RETSIGTYPE} to be
-@code{void}; otherwise, define it to be @code{int}.
-
-Define signal handlers as returning type @code{RETSIGTYPE}:
-
-@example
-@group
-RETSIGTYPE
-hup_handler ()
-@{
-@dots{}
-@}
-@end group
-@end example
-@end defmac
-
 @anchor{AC_TYPE_SIZE_T}
 @defmac AC_TYPE_SIZE_T
 @acindex{TYPE_SIZE_T}
@@ -19220,7 +19203,8 @@ issue.
 
 @defmac AC_RETSIGTYPE
 @acindex{RETSIGTYPE}
-Replaced by @code{AC_TYPE_SIGNAL} (@pxref{AC_TYPE_SIGNAL}).
+Replaced by @code{AC_TYPE_SIGNAL} (@pxref{AC_TYPE_SIGNAL}), which itself
+is obsolete when assuming C89 or better.
 @end defmac
 
 @defmac AC_RSH
@@ -19480,6 +19464,31 @@ AC_RUN_IFELSE(
 @xref{Runtime}.
 @end defmac
 
+@anchor{AC_TYPE_SIGNAL}
+@defmac AC_TYPE_SIGNAL
+@acindex{TYPE_SIGNAL}
+@cvindex RETSIGTYPE
+@hdrindex{signal.h}
+If @file{signal.h} declares @code{signal} as returning a pointer to a
+function returning @code{void}, define @code{RETSIGTYPE} to be
+@code{void}; otherwise, define it to be @code{int}.  These days, it is
+portable to assume C89, and that signal handlers return @code{void},
+without needing to use this macro or @code{RETSIGTYPE}.
+
+When targetting older K&R C, it is possible to define signal handlers as
+returning type @code{RETSIGTYPE}, and omit a return statement:
+
+@example
+@group
+RETSIGTYPE
+hup_handler ()
+@{
+@dots{}
+@}
+@end group
+@end example
+@end defmac
+
 @defmac AC_UID_T
 @acindex{UID_T}
 Replaced by @code{AC_TYPE_UID_T} (@pxref{AC_TYPE_UID_T}).
diff --git a/lib/autoconf/types.m4 b/lib/autoconf/types.m4
index 866bdca..50a489c 100644
--- a/lib/autoconf/types.m4
+++ b/lib/autoconf/types.m4
@@ -1,8 +1,8 @@
 # This file is part of Autoconf.			-*- Autoconf -*-
 # Type related macros: existence, sizeof, and structure members.
 #
-# Copyright (C) 2000, 2001, 2002, 2004, 2005, 2006, 2007 Free Software
-# Foundation, Inc.
+# Copyright (C) 2000, 2001, 2002, 2004, 2005, 2006, 2007, 2008 Free
+# Software Foundation, Inc.
 #
 # This program is free software: you can redistribute it and/or modify
 # it under the terms of the GNU General Public License as published by
@@ -693,8 +693,10 @@ AC_DEFUN([_AC_TYPE_UNSIGNED_INT],
 # AC_TYPE_SIGNAL
 # --------------
 # Note that identifiers starting with SIG are reserved by ANSI C.
-AN_FUNCTION([signal],  [AC_TYPE_SIGNAL])
-AC_DEFUN([AC_TYPE_SIGNAL],
+# C89 requires signal handlers to return void; only K&R returned int;
+# modern code does not need to worry about using this macro (not to
+# mention that sigaction is better than signal).
+AU_DEFUN([AC_TYPE_SIGNAL],
 [AC_CACHE_CHECK([return type of signal handlers], ac_cv_type_signal,
 [AC_COMPILE_IFELSE(
 [AC_LANG_PROGRAM([#include <sys/types.h>
@@ -706,7 +708,8 @@ AC_DEFUN([AC_TYPE_SIGNAL],
 AC_DEFINE_UNQUOTED(RETSIGTYPE, $ac_cv_type_signal,
 		   [Define as the return type of signal handlers
 		    (`int' or `void').])
-])
+], [your code may safely assume C89 semantics that RETSIGTYPE is void.
+Remove this warning and the `AC_CACHE_CHECK' when you adjust the code.])
 
 
 ## ------------------------ ##
-- 
1.5.5.1

_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf

[Index of Archives]     [GCC Help]     [Kernel Discussion]     [RPM Discussion]     [Red Hat Development]     [Yosemite News]     [Linux USB]     [Samba]

  Powered by Linux