Date: Thu, 31 Jan 2002 01:10:20 -0700 From: Wes Peters <wes@softweyr.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: Jeroen Ruigrok/asmodai <asmodai@wxs.nl>, Kirk McKusick <mckusick@mckusick.com>, arch@FreeBSD.ORG, Peter Wemm <peter@wemm.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: <3C58FBEC.746257BB@softweyr.com> References: <68578.1012450924@winston.freebsd.org> <200201310701.g0V71Ci75803@beastie.mckusick.com> <20020131072933.GQ22384@daemon.ninth-circle.org> <3C58F78E.3F66EA8E@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote:
>
> Jeroen Ruigrok/asmodai wrote:
> > Which items can we identify to tackle in this effort?
> >
> > - Get rid of __P() macros in source files
> > - Use proper ANSI prototypes, this flows from the point above
Sort of. If you mean "edit the __P() macros into prototypes with the
same footprint", that's a good starting point. A logical next step
would be to check each of our newly prototyped functions against
Posix/SUS and become more standards compliant.
> > what else?
>
> Other candidates are other macros in cdefs.h; because of the
> __attribute stuff, I would be loathe to get rid of it entirely,
> since it encapsulates some GCC dependence/independence, but the
> const/void/volatile definitions are a possibility.
>
> There are also the varradic function declarations, which are
> not all ANSI-C style, yet, use of __STRING and __CONCAT, etc..
>
> My recommendation would be to do __P() first, now that there
> is a cross-BSD consensus, and leave other changes for other
> discussions.
Always a sensible choice, just to keep the CVS commits atomic if no
other reason.
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
wes@softweyr.com http://softweyr.com/
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?3C58FBEC.746257BB>
