Date: Tue, 14 Jan 2003 23:17:28 +0000 From: Keith Jones <freebsd.dev@blueyonder.co.uk> To: Terry Lambert <tlambert2@mindspring.com> Cc: Bruce Evans <bde@zeta.org.au>, Jake Burkholder <jake@locore.ca>, sparc@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: [PATCH] Re: fpsetmask on sparc64 Message-ID: <3E249A88.7030109@blueyonder.co.uk> In-Reply-To: <20030113200018.P11690-100000@gamplex.bde.org> References: <20030113200018.P11690-100000@gamplex.bde.org> <3E2321CF.A5835FCD@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote: > If a legacy application stops working because a system changes, > it's the fault of the system doing the changing, not the fault of > the people back in 1984 who didn't know ANSI was going to bung-up > the C language until their application no longer worked. > > There has to be some allowance for the continuity of code; it > can't just be orphaned instantaneously, without some warning > from the system vendor. I'm new to this list, so apologies if this has been stated before, but having just discovered that /usr/include/malloc.h has gone from being merely deprecated (in -STABLE) to obsolete (in -RC), I'm with Terry on this one. Yes it may be the right thing to do from a standards point of view, but there's still a lot of legacy code out there that uses it. (And a lot of new code too, I'll bet, since malloc.h still works fine and dandy on Linux, and despite the fact that the man page has said '#include <stdlib.h>' for a few years now, developers still fail to RTFM, it appears.) Okay, it's only a small thing, but if you have too many of these small things to deal with at once, you're in porting Hell. ;) Keith To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E249A88.7030109>