Date: Sun, 3 Jul 2011 12:34:34 +0200 From: Robert Millan <rmh@debian.org> To: Alexander Kabaev <kabaev@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] __FreeBSD_kernel__ Message-ID: <CAOfDtXPfhreqnd06sB4m%2BPhTSwCqD4TEwP5uC_Tp8U30o6Lg1g@mail.gmail.com> In-Reply-To: <20110702193724.5c55a6c9@kan.dnsalias.net> References: <CAOfDtXPUxQO1zbnxh8sh%2By7g=d8QaH2svYtEQJ06L4d%2BQKG8VA@mail.gmail.com> <20110702193724.5c55a6c9@kan.dnsalias.net>
next in thread | previous in thread | raw e-mail | index | archive | help
2011/7/3 Alexander Kabaev <kabaev@gmail.com>:
> I do not think this belongs in GCC at all. You should already have a
> defined symbol to identify your OS and that should be used in cases
> where it matters.
If we wanted to identify the OS as a whole, we can currently do this
with something like:
"#if defined(__FreeBSD_kernel__) && defined(__GLIBC__)"
however, in practice this never happens. What almost every check
wants is either to know about our userland APIs (hence __GLIBC__) or
to know about our kernel APIs (then __FreeBSD_kernel__).
In both cases, the check also wants to match other operating systems
(FreeBSD when it comes to kernel API checks, and GNU/{Linux,Hurd} when
it comes to userland API checks). Using macros that are shared (like
__GLIBC__) or that could potentially be shared (like
__FreeBSD_kernel__) with other operating systems maximizes the
opportunities to:
a) produce simpler checks like "#ifdef __GLIBC__" which are easier to
read and maintain.
b) collaborate with other projects by producing patches which have the
collateral effect of improving portability with other operating
systems.
--
Robert Millan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOfDtXPfhreqnd06sB4m%2BPhTSwCqD4TEwP5uC_Tp8U30o6Lg1g>