() Bob Friesenhahn [EMAIL PROTECTED]
() Tue, 10 Jun 2008 10:10:20 -0500 (CDT)
Economic incentive has little to do with open source.
Time is limited for everyone.
thi
___
Autoconf mailing list
Autoconf@gnu.org
Bob Friesenhahn [EMAIL PROTECTED] writes:
I recall having to deal with this
issue on fairly recent systems in the 1996-98 timeframe so 'int'
didn't just go away because ANSI C said so.
Yes, absolutely; it took quite some time for those old systems to die
off. But they have been dead for at
Hello,
On Mon, Jun 09, 2008 at 10:40:02PM -0500, Bob Friesenhahn wrote:
I recall having to deal with this issue on fairly recent systems in the
1996-98 timeframe so 'int' didn't just go away because ANSI C said so.
IIRC, the same was said on this thread earlier. It's about ten years
since
On Tue, 2008-06-10 at 00:36 -0700, Paul Eggert wrote:
Bob Friesenhahn [EMAIL PROTECTED] writes:
I recall having to deal with this
issue on fairly recent systems in the 1996-98 timeframe so 'int'
didn't just go away because ANSI C said so.
Yes, absolutely; it took quite some time for
Bob Friesenhahn [EMAIL PROTECTED] writes:
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 exaggerating to make a point, but indeed, this is mostly true of
the
On Tue, 10 Jun 2008, Paul Eggert wrote:
Yes, absolutely; it took quite some time for those old systems to die
off. But they have been dead for at least a decade. It's time to
move on.
A minimum of 10 years of coverage seems good to me. 12 years is a
good maximum limit. 5 or 7 years is
(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 [EMAIL PROTECTED]
---
ChangeLog |6 +
doc/autoconf.texi
Paul wrote:
Eric Blake [EMAIL PROTECTED] writes:
2008-06-09 Eric Blake [EMAIL PROTECTED]
+ 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
(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 [EMAIL PROTECTED]
---
ChangeLog |6 +
doc/autoconf.texi
Eric Blake [EMAIL PROTECTED] writes:
2008-06-09 Eric Blake [EMAIL PROTECTED]
+ 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
Paul wrote:
Eric Blake [EMAIL PROTECTED] writes:
2008-06-09 Eric Blake [EMAIL PROTECTED]
+ 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
-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
On Mon, 9 Jun 2008, Eric Blake wrote:
| 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
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
On Sat, 7 Jun 2008, Bob Friesenhahn wrote:
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bob Friesenhahn on 6/7/2008 10:01 AM:
| 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
On Sat, 7 Jun 2008, Eric Blake wrote:
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
Bob Friesenhahn [EMAIL PROTECTED] writes:
I will retract this statement. I just checked each of my current porting
targets and they all seem to return the 'void' type from signal handlers.
This includes several systems released in 1997.
Yeah, I don't remember the last time I saw a system
Any objections to making AC_TYPE_SIGNAL obsolete (with the recommendation of
replacing RETSIGTYPE with void in old code), since even C89 requires signal
handlers to return void?
--
Eric Blake
___
Autoconf mailing list
Autoconf@gnu.org
http
On Fri, 6 Jun 2008, Eric Blake wrote:
Any objections to making AC_TYPE_SIGNAL obsolete (with the recommendation of
replacing RETSIGTYPE with void in old code), since even C89 requires signal
handlers to return void?
Why are you interested in making this change? Is the macro causing
problems
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bob Friesenhahn on 6/6/2008 8:42 PM:
| On Fri, 6 Jun 2008, Eric Blake wrote:
|
| Any objections to making AC_TYPE_SIGNAL obsolete (with the
| recommendation of
| replacing RETSIGTYPE with void in old code), since even C89 requires
21 matches
Mail list logo
