-----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 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 iEYEARECAAYFAkhN4u4ACgkQ84KuGfSFAYDglQCgp0lwxhhyXgY6mkOJ32i0ITTt Qt4AnAv6gmxlQOXL4ZXH86wGsVYIazdr =aNLK -----END PGP SIGNATURE----- _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
