Re: AC_TYPE_SIGNAL obsolete?

[Bob Friesenhahn]

On Fri, 6 Jun 2008, Eric Blake wrote:
> |
> | Why are you interested in making this change?  Is the macro causing
> | problems?  Try as we might, we can't change history and so this macro
> | may be useful on many systems which are still in use.
>
> Marking a macro obsolete does not mean that existing projects have 
> to remove it, nor that we will break its behavior.  Rather, it means 
> that new projects don't have to worry about needing to use it (if 
> you assume C89, which most projects do these days, then 
> AC_TYPE_SIGNAL is a waste of ./configure time).  In other words, it 
> can simplify maintenance to realize this is no longer a relevant 
> porting concern.

My own project does include support for signal handlers which return 
'int'.  It is using this macro.  Without this provision, the code 
would fail to compile on some systems due to prototype mismatch. 
Original POSIX.1 specifically allowed signal handlers to return void 
or int so the interface is POSIX compliant.  This makes it different 
than some legacy interface which was never blessed by POSIX.

The C compiler should not be confused with the supportive libraries. 
For example, GCC does not provide replacement functionality to bring 
vendor C libraries up to the latest ANSI C specification.  It is quite 
common to have a reasonably modern GCC which relies on legacy vendor 
libraries.

> My motivating example is the gnulib module c-stack, which blindly assumes
> that signal handlers with void return types can be installed rather than
> worrying about using RETSIGTYPE; no one has complained about being unable
> to compile it on their platforms.

Previously you described that gnulib has rather unambitious goals for 
supporting old OS releases (5 years?). This makes it an unsuitable 
benchmark for applying decisions in autoconf, which is supposed to be 
enabling software portability across a broad range of targets.  While 
it may be that you don't consider this old issue to be a valid porting 
concern, some packages definitely will.  For example, if I was the 
maintainer of xntp, or a Unix shell, I would definitely remain 
concerned about this issue.  My package is only an image processing 
package, yet several advertized porting targets (which I still test 
on) are impacted by this issue.

The decision as to whether this issue is still relevant should be a 
concern of the package maintainer and not an autoconf maintainer.

Bob
======================================
Bob Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/