From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 5 09:45:14 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 213331065670 for ; Thu, 5 Jun 2008 09:45:14 +0000 (UTC) (envelope-from nlcom_os@ii.nl) Received: from mail1.ii.nl (mail1.ii.nl [82.94.191.120]) by mx1.freebsd.org (Postfix) with ESMTP id D28838FC18 for ; Thu, 5 Jun 2008 09:45:13 +0000 (UTC) (envelope-from nlcom_os@ii.nl) Received: from c53751d89.cable.wanadoo.nl ([83.117.29.137]:58584 helo=[192.168.1.103]) by mail1.ii.nl with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) authenticated as nanno with plain authenticator (Exim 4.63) (envelope-from ) id 1K4C0d-0006WE-I7; Thu, 05 Jun 2008 11:43:51 +0200 Message-ID: <4847B552.9070807@ii.nl> Date: Thu, 05 Jun 2008 11:43:46 +0200 From: Nanno Langstraat User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Max Laier References: <4847182F.80105@ii.nl> <200806050119.24405.max@love2party.net> In-Reply-To: <200806050119.24405.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Standard byteorder functions across BSD / Linux X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2008 09:45:14 -0000 Max Laier wrote: > On Thursday 05 June 2008 00:33:19 Nanno Langstraat wrote: > >> * or ? >> I maintain that it should be for user applications: >> IMHO 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 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 is automatically pulled in by common things like and . On FreeBSD, a newly introduced 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