autoconf-patches
[Top][All Lists]
Advanced

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

Re: AC_TYPE_SIGNAL obsolete?


From: Eric Blake
Subject: Re: AC_TYPE_SIGNAL obsolete?
Date: Mon, 09 Jun 2008 06:27:03 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) Gecko/20080421 Thunderbird/2.0.0.14 Mnenhy/0.7.5.666

-----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             address@hidden
-----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 <address@hidden>
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 <address@hidden>
---
 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  <address@hidden>
 
+       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}
address@hidden @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
 
address@hidden
address@hidden AC_TYPE_SIGNAL
address@hidden
address@hidden RETSIGTYPE
address@hidden
-If @file{signal.h} declares @code{signal} as returning a pointer to a
-function returning @code{void}, define @code{RETSIGTYPE} to be
address@hidden; otherwise, define it to be @code{int}.
-
-Define signal handlers as returning type @code{RETSIGTYPE}:
-
address@hidden
address@hidden
-RETSIGTYPE
-hup_handler ()
address@hidden
address@hidden
address@hidden
address@hidden group
address@hidden example
address@hidden 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
 
address@hidden
address@hidden AC_TYPE_SIGNAL
address@hidden
address@hidden RETSIGTYPE
address@hidden
+If @file{signal.h} declares @code{signal} as returning a pointer to a
+function returning @code{void}, define @code{RETSIGTYPE} to be
address@hidden; 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:
+
address@hidden
address@hidden
+RETSIGTYPE
+hup_handler ()
address@hidden
address@hidden
address@hidden
address@hidden group
address@hidden example
address@hidden 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]