Date: Wed, 30 Jan 2002 01:04:16 -0700 (MST) From: "M. Warner Losh" <imp@village.org> To: deatley@apple.com Cc: arch@FreeBSD.ORG Subject: Re: __P macro question Message-ID: <20020130.010416.109979400.imp@village.org> In-Reply-To: <FD5651F8-1537-11D6-993F-003065766C3C@apple.com> References: <FD5651F8-1537-11D6-993F-003065766C3C@apple.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <FD5651F8-1537-11D6-993F-003065766C3C@apple.com>
Dallas De Atley <deatley@apple.com> writes:
: My question was: What is the __P macro used for in all those
: function declarations in the BSD libraries and do we still need it?
It is there for K&R support for the most part. Although there may be
some sneaky uses of it that may make it a little difficult to blindly
remove.
: Is the __P macro still necessary?
No.
: Are there pre ANSI C compilers
: FreeBSD wishes to support or is this macro effectively benign but
: useless?
Not really. There are a few in the FreeBSD community that would like
to continue to support this. However, even they admit that removing
uses of the __P macro in the tree would be a good thing.
However, there are several caveats:
1) Wholesale removal of this macro would likely cause merge
conflicts to those using the p4 repository and who are
otherwise maintaining separate projects. Since these are
the cool new projects, it is widely believed that some
level of coordination is needed with these products. This
is especially true in the kernel.
2) There are style(9) concerns about naive removal methods,
and a few other asthetic considerations as well.
3) There are concerns about how easy/hard it will be to merge
changes after we do this to prior branches.
The last time this came up in any real way, the folks with the
pitchforks and pitch-oil that wanted to get rid of the thing were
placated by the promise that it would be done as part of the glide
path to the 5.0 release. I'm not sure which side of the release it
will be done on, but I think the thought was before the 5.x-stable
branch is created so that while we're working on 6.0 we can MFC
changes to the 5.x-branch. This makes it hard on the 4.x branch, but
less hard than if we had to do both 5.x and 4.x __P twingling.
But I'm not sure that there is an appointed executioner, or an exact
timetable for this change to take place.
Warner
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?20020130.010416.109979400.imp>