Date: Wed, 30 Jan 2002 23:01:12 -0800 From: Kirk McKusick <mckusick@mckusick.com> To: arch@FreeBSD.ORG Cc: Terry Lambert <tlambert2@mindspring.com>, Peter Wemm <peter@wemm.org>, Garance A Drosihn <drosih@rpi.edu>, Alfred Perlstein <bright@mu.org>, Poul-Henning Kamp <phk@critter.freebsd.dk>, Dallas De Atley <deatley@apple.com>, Jordan Hubbard <jkh@winston.freebsd.org>, "Perry E. Metzger" <perry@wasabisystems.com>, "Todd C. Miller" <Todd.Miller@courtesan.com>, Theo de Raadt <deraadt@cvs.openbsd.org> Subject: Re: __P macro question Message-ID: <200201310701.g0V71Ci75803@beastie.mckusick.com> In-Reply-To: Your message of "Wed, 30 Jan 2002 20:22:04 PST." <68578.1012450924@winston.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
As the initial perpetrator of __P(()) I will be the Nth to say (where N is a distressingly large number) that its usefulness has long gone. Since a big objection has been coordinating with the other BSD's, I took the liberty of asking them (see responses below). They are just as eager to get rid of it, but have been waiting for the other BSD's as well. Time's up. We all agree, __P(()) should be history. Let's all just set about making it so and get on with something important. Kirk McKusick =-=-=-=-= From: "Perry E. Metzger" <perry@wasabisystems.com> To: Kirk McKusick <mckusick@McKusick.COM> Cc: perry@wasabisystems.com Subject: Re: __P(()) Macro Date: 30 Jan 2002 23:41:35 -0500 Kirk McKusick <mckusick@mckusick.com> writes: > The FreeBSD mailing list is having their annual debate about removing > the __P(()) macro. While it is generally agreed that its time has come > and gone, one of the big remaining stumbling blocks is to avoid > introducing massive gratuitous code differences with the other BSD > varients. So, I would like to find out if NetBSD has any interest > in going on a systematic purge of __P(()) so that all the groups > could move together at roughly the same time. I think there is widespread interest in doing so. One of our major concerns has been gratuitous code differences vs. other BSDs, but if FreeBSD moved at the same time it might be a much smaller problem. Some scripts should be able to manage the heavy lifting pretty easily and would be simple to share. By the way, our latest style guide says all *new* code is ANSI, but you're generally only supposed to change old code if you're reworking a file for other reasons. -- Perry E. Metzger perry@wasabisystems.com -- NetBSD Development, Support & CDs. http://www.wasabisystems.com/ =-=-=-=-=-= To: Kirk McKusick <mckusick@mckusick.com> cc: Theo de Raadt <deraadt@cvs.openbsd.org> Subject: Re: __P(()) Macro Date: Wed, 30 Jan 2002 20:33:34 -0700 From: "Todd C. Miller" <Todd.Miller@courtesan.com> [ Theo is out of the country and generally w/o net access for another couple of weeks]. In message <200201310328.g0V3Sci74844@beastie.mckusick.com> so spake Kirk McKusick (mckusick): > FreeBSD's current policy is also not to use __P(()) in new code. > The current proposal is to simply remove the __P(()), not to convert > the function headers (which may be a reasonable thing to do, but is > not part of the current plan). Ah, OK then that is not a big deal at all. I did a straw poll among OpenBSD folks active on our icb server and no one objects to this. > I concur that lex and yacc should be able to generate K&R code, but > probably not using __P(()). Rather grouping all the function > prototypes into one place and putting some sort of ifdef around them. Yes, that sounds prefectly reasonable. - todd 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?200201310701.g0V71Ci75803>