Date: Thu, 05 Jun 2008 11:43:46 +0200 From: Nanno Langstraat <nlcom_os@ii.nl> To: Max Laier <max@love2party.net> Cc: freebsd-hackers@freebsd.org Subject: Re: Standard byteorder functions across BSD / Linux Message-ID: <4847B552.9070807@ii.nl> In-Reply-To: <200806050119.24405.max@love2party.net> References: <4847182F.80105@ii.nl> <200806050119.24405.max@love2party.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Max Laier wrote:
> On Thursday 05 June 2008 00:33:19 Nanno Langstraat wrote:
>
>> * <endian.h> or <sys/endian.h> ?
>> I maintain that it should be <endian.h> for user applications:
>> IMHO <sys/> is for the user-kernel API, and byteorder belongs to
>> libc not the kernel API.
>> glibc apparently agrees, OpenBSD disagreed.
>>
>
> Not sure about this. There might be namespace issues with this approach,
> though there probably shouldn't.
True. However, glibc (i.e. Linux) has had the file <endian.h> for a long
time. (That's probably why Ulrich Drepper simply added the new macros
there)
Since they're something of an "800 pound gorilla", I don't think it'll
be an additional hazard for BSD to add that file to the top-level file
namespace.
In fact, glibc are taking an extra risk, because their pre-existing
<endian.h> is automatically pulled in by common things like <ctype.h>
and <pthread.h>.
On FreeBSD, a newly introduced <endian.h> can sit there innocently, and
only be pulled in by user applications that explicitly know about it.
> It's obviously not a problem to have
> both, but getting rid of sys/endian.h now is too late for sure.
>
Agree, won't disappear, even if only because the kernel uses it.
Nanno
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4847B552.9070807>