Re: AC_SYS_RESTARTABLE_SYSCALLS

[Paul Eggert]

Ian Lance Taylor <address@hidden> writes:

> UUCP is GNU code which uses it.

Sorry, I didn't know about it.


> > > not every system supports SA_RESTART
> > 
> > Which systems don't?  That info would be good to add to the manual.
> 
> I'm thinking of older systems.  As far as I know SA_RESTART was
> introduced by Solaris.  I doubt it is in SVR4.2, for example, though I
> admit that I don't have a way to check.

Rich Stevens wrote in 1991 that SA_RESTART was in SVID Issue 3,
in SVR4, and in 4.3BSD Reno.  See:
<http://groups.google.com/groups?selm=1991Jul31.185303.5583%40noao.edu>


> I checked Ultrix 4.0, and it has sigaction but does not have SA_RESTART.

That was released in 1990, right?  It was probably based on 4.3BSD
Tahoe then, and I guess Tahoe didn't have it.  Reno came out in June 1990.


> AC_DEFUN([AC_SYS_RESTARTABLE_SYSCALLS],
> [AC_DIAGNOSE([obsolete],
> [$0: System call restartability is now typically set at runtime.
> Remove this `AC_SYS_RESTARTABLE_SYSCALLS'
> and adjust your code to use `sigaction' with `SA_RESTART' instead.])dnl

Perhaps that's a bit draconian.  Can you suggest a better wording for
that diagnostic?


> Sure, but why is it obsolete?

It's marked obsolete because of my survey.  I didn't know of anybody
that was using it correctly.  (Bash was using it, but incorrectly.)

Also, one big problem with AC_SYS_RESTARTABLE_SYSCALLS is that it
doesn't work when cross-compiling.  This is another reason to
deprecate it.  I notice that uucp guesses when cross-compiling.

Wouldn't it be better for uucp to determine the value dynamically?
That should be fairly easy to do, by running a bit of test code.  Then
you wouldn't need to guess, and you wouldn't need
AC_SYS_RESTARTABLE_SYSCALLS either.  (You would need an ancient system
to test it on, but I guess if you have Ultrix 4.0 then that is ancient
enough.  :-)


> For me I guess it's a philosophical issue.  I think the point of
> autoconf is to support a wide range of systems, including systems
> which were created 10 years ago.  For example, in 1992 I ported UUCP
> to SVR2 systems which had been built in 1984; autoconf was very
> helpful.

Yes, but SVR2 was released in April 1984, so it's now nearly a 20-year
old system.  Nobody ports to SVR2 any more.  Or to SVR3 (released
1986).  These are all dead systems, outside of museums.  Perhaps there
are a few of them running production somewhere, but nobody ports
software to them.

Ultrix 4.0 is a bit newer, but it's pretty much dead as well.  There
are still a few hobbyists running ancient Ultrix 4.0 castoff hardware,
I suppose, but the most recent report I found on Usenet of anyone
trying to port software of any kind to Ultrix 4.0 was dated May 1998.
Here it is:
<http://groups.google.com/groups?q=%22Ultrix+4.0%22&selm=35225D0C.1D5EFCDD%40huntleigh.net>
Five years of inactivity is a pretty good sign that the OS is dead,
from autoconf's point of view.


> What is the current autoconf philosophy?  How old should systems be
> before they are no longer supported?

It's a judgment call, but basically if there isn't any serious usage
outside of computer museums, then we shouldn't have to worry about it.


> To put it another way, when can autoconf start using shell functions?

We discussed this a few months ago; I vaguely recall that the
consensus was that it's OK to use shell functions in new macros but
we'll hold off converting the old stuff for a while.  'configure'
scripts now try pretty hard to find a POSIX shell, even if /bin/sh
isn't POSIX, so shell functions should be pretty safe.