From owner-freebsd-arch Wed Jan 30 11: 5:32 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 7879537B43C for ; Wed, 30 Jan 2002 11:05:05 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id g0UJ50J120360; Wed, 30 Jan 2002 14:05:00 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: Date: Wed, 30 Jan 2002 14:04:58 -0500 To: Dallas De Atley , arch@FreeBSD.ORG From: Garance A Drosihn Subject: Re: __P macro question Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 8:15 PM -0800 1/29/02, Dallas De Atley wrote: > After doing a little bit of homework searching cdef.h and >style.9 and encountering old jokes concerning the coming of Jesus >(thank you Google), I decided to pursue the question. > > Is the __P macro still necessary? Are there pre ANSI C >compilers FreeBSD wishes to support or is this macro effectively >benign but useless? We (freebsd developers) have this debate every six months or so. Each time, the overwhelming majority of developers will be happy to see __P() disappear. However, there is also general agreement that we shouldn't do some big sweep of the code just to remove __P()'s. So, the feeling is that if you are changing some section of code for some other reason, then it would be a fine idea to also write an update (a separate update...) which would "ANSI-fy" the code. One exception to this is the main system include libraries. The feeling seems to be that these could wait, and if these are switched at all then they can be the last things switched over. So, several months go by, some new person comes along, and asks the question again. Then all the people who want to KEEP the __P()'s act as if this is some brand new issue, and that we must debate it to death once again. I think no debate is necessary. The decision has already been reached, several times, that __P() can go. Anyone who makes an update to ANSI-fy some code will probably get some grumbling about "breaking K&R conformance", but at this point I think that specific complaint should just be ignored. The year is now 2002, and not 1988. I also think that maybe we *do* need a specific code-sweep which does nothing but (carefully) remove all the __P()'s, if for no other reason than to avoid seeing this debate again in six to eight months. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message