Date: Wed, 30 Jan 2002 01:20:08 -0800 From: Jordan Hubbard <jkh@winston.freebsd.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: Dallas De Atley <deatley@apple.com>, arch@FreeBSD.ORG Subject: Re: __P macro question Message-ID: <64972.1012382408@winston.freebsd.org> In-Reply-To: Message from Terry Lambert <tlambert2@mindspring.com> of "Wed, 30 Jan 2002 00:55:55 PST." <3C57B51B.F38D1906@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Ye flippin' gods! My hat is off to you, Terry. You've managed to effectively segue from the question of using __P() macros to hide ANSI C function declarations to a debate on the wisdom of using GCC extentions and whether or not to open-source various other types of compiler technology. It's no wonder the __P() stuff is still there if just pulling on a little string brings a truck rolling toward you. :-) I think writing portable C code as a general practice is an entirely tangental subject and one probably worthy of an entire series of encyclopedic volumes on the topic. To focus on this one *specific* issue in -arch, however, I think the debate needs to confine itself for the moment to one point and one point only: Is the set of C compilers which FreeBSD, or any directly-derived variant thereof, is likely to encounter in real life going to include one which does not grok the more modern, non-GCC specific language constructs (reminder: function prototypes) which were oh-so-long-ago approved by the ANSI committee? If the answer is "no", and I think it quite reasonably might be, then we can move forward with at least one assumption and that's that __P() can die in FreeBSD as something which merely obfuscates and renders our code more unpleasant to the eye. The old "reference" code will certainly live on in Net/1, Net/2 and all the ancient Unix code which Caldera was so recently kind enough to release back to the public and anyone needing "reference bits" for ancient hardwawre is probably not going to be well-served by FreeBSD anyway. As you point out, FreeBSD has trod the Path of Evil in the form of using gcc extentions to quite an extent and to worry about __P() or even assume that any measurable incremental value can truly be afforded by keeping it around is just silly, like spraying Lysol on a cow patty. If you want my vote, and you get it whether that's the case or not, I say we nuke __P() from orbit until it and the unlucky disk platters it formerly rested on are reduced to a molten, bubbly, radioactive slag with the merest hint of ferrous particles still coating the surface. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?64972.1012382408>