Re: AC_TYPE_SIGNAL obsolete?

[Eric Blake]

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

[dropping autoconf-patches]

According to Harlan Stenn on 6/9/2008 3:27 PM:
|>> +     Mark AC_TYPE_SIGNAL as obsolete.
|> Thanks for doing this; it makes sense to me.  Signal handlers
|> returning 'int' became obsolete on all C platforms as of the first C
|> standard in 1989.  In practice they were obsolete even before that.
|> This is beyond even Autoconf's broad porting horizon.
|
| I think you are dead wrong on your last point, Paul.

There's a difference between obsolete compliance (and yes, Paul is right
that C compilers that required signal handlers with return type of int
were implicitly made obsolete 19 years ago when C89 was standardized) and
obsolete platforms (vendors will actively support software that is several
years behind the compliance curve, and we do not consider them obsolete
platforms - so it was only within the last 2 or 3 years that you no longer
had to worry about things like vendor-supplied compilers where signal
handlers had to return int).  In fact, C89 is obsolete in standards terms
(replaced by C99 which itself is 9 years old), but the number of viable
vendor-supported platforms that support C89 but not C99 is so large that
autoconf still actively caters to those platforms.

|
| I 'deprecated' K&R C support for NTP not all that long ago.

And which platforms did NTP target where K&R C was the only way that you
could compile your project?  I'm serious - unless we know of a
counterexample to prove our claim wrong, then we stand by our position
that adding/maintaining portability hacks to support K&R C is no longer a
necessary prerequisite when porting software that targets the vast
majority of vendor-supported platforms.  But at the same time, we are NOT
crippling K&R portability.  There is nothing wrong with leaving existing
K&R support in place if you don't have the time to clean up your code; and
you may STILL use AC_TYPE_SIGNAL if you _really_ want to port to K&R
platforms.  All you have to do is simply ignore the obsoletion warning.

|
| And the only reason I have not been more vocal on this thread is because
| ntp may be stuck with autoconf 2.61 for the long-haul because of GPLv3
| concerns, so changes to autoconf after 2.61 may not matter to NTP.

What is your GPLv3 concern?  Autoconf 2.62 is GPLv2+ plus exception, under
the exact same licensing terms as Autoconf 2.61, so I don't see where your
concern is stemming from.  I would like to be enlightened as to where you
perceive the issue to be; without describing it, we will be unable to help
you resolve it, or even at least forward it on to the FSF lawyers to weigh
in on while they continue working on the eventual GPLv3+ plus exception
that we hope to migrate to in some future release.

- --
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

iEYEARECAAYFAkhN4u4ACgkQ84KuGfSFAYDglQCgp0lwxhhyXgY6mkOJ32i0ITTt
Qt4AnAv6gmxlQOXL4ZXH86wGsVYIazdr
=aNLK
-----END PGP SIGNATURE-----