From owner-freebsd-hackers Wed May 7 09:58:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA01767 for hackers-outgoing; Wed, 7 May 1997 09:58:03 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id JAA01752 for ; Wed, 7 May 1997 09:57:57 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA21295; Wed, 7 May 1997 09:52:07 -0700 From: Terry Lambert Message-Id: <199705071652.JAA21295@phaeton.artisoft.com> Subject: Re: /usr/include/ftpio.h is not C++ safe To: michaelh@cet.co.jp (Michael Hancock) Date: Wed, 7 May 1997 09:52:06 -0700 (MST) Cc: terry@lambert.org, jkh@time.cdrom.com, bde@zeta.org.au, nadav@barcode.co.il, hackers@FreeBSD.ORG In-Reply-To: from "Michael Hancock" at May 7, 97 11:26:34 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > > I hate __P() and will fight a guerilla war against it if I have to. > > > > > > So do I. I'd do it in straight ANSI first and then if there's an uproar > > > of people who can provide details of their K&R applications that require > > > __P() then you can begrudgingly add it later. > > > > Cool. You guys sound like Sun Microsystems statistically adressing > > sev 1 bugs. > > On the contrary, a consistent interface exclusively tailored for new code > reduces the spec and this increases the chances of delivering bug free > code for the class of new apps that would use the lib. I meant in terms of "We'll do it this obviously unpopular way, and if there's an uproar, well then we'll go back and do it again the way the uproar wants". The sword of Damocles cuts both ways: it is just as bad to cave to popular opinion as it is to do something in an obvious unpopular way for personal preferences on "style". It's "politicl correctness" vs. "rightious indignation", with no reasonable middle ground. That's what sounded like Sun Microsystems handling a SunOS bug, to me. Of course, I've only been on the customer side of the Sun Microsystems process, so maybe it's not as clear as I paint it. My favorite sev 1 bug on SunOS 2.x is "the code is derived from SVR4; system will not operate". 8-). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.