From owner-freebsd-arch Wed Jan 30 1:37:40 2002 Delivered-To: freebsd-arch@freebsd.org Received: from snipe.prod.itd.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id 4145637B402 for ; Wed, 30 Jan 2002 01:37:34 -0800 (PST) Received: from pool0125.cvx40-bradley.dialup.earthlink.net ([216.244.42.125] helo=mindspring.com) by snipe.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16VrBK-0005nW-00; Wed, 30 Jan 2002 01:37:30 -0800 Message-ID: <3C57BED2.E1144F41@mindspring.com> Date: Wed, 30 Jan 2002 01:37:22 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jordan Hubbard Cc: Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question References: <64972.1012382408@winston.freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Jordan Hubbard wrote: > 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? You mean like when I compile "grep" and other command line tools on my Amiga using Manx Aztec C, a K&R compiler? Or when I use Watcom to take some FreeBSD code for a POS system to do the same thing for DR-DOS, because GCC won't run there because it can't be compiled to use overlays? Really, if someone can't understand __P(), they should probably not be in the kernel, with all those "dangerous" linker sets and other less obvious code than __P()... > 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. I think that portability of code between FreeBSD and OpenBSD and NetBSD is a concern, and I think increasing the diffs gratuitously between these systems is a Bad Idea(tm). Also, as has already been raised, there is an issue of doing back-ports of the code to FreeBSD X.Y, where X.Y is and of the versions prior to the cosmetic make-over. When NetBSD or OpenBSD gets new code (e.g. the SYN cache code or the ipfilter license-inspired replacement), it would be nice if porting the code would not require a human going through and deciding which differences are there because they need to be there, and which ones are there because of gratuitous cosmetic changes. > 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. Can you get BSDI, NetBSD, and OpenBSD to go along with this? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message