Date: Wed, 30 Jan 2002 01:37:22 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Jordan Hubbard <jkh@winston.freebsd.org> Cc: Dallas De Atley <deatley@apple.com>, arch@FreeBSD.ORG Subject: Re: __P macro question Message-ID: <3C57BED2.E1144F41@mindspring.com> References: <64972.1012382408@winston.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C57BED2.E1144F41>