From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 24 17:15:22 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31A6516A4CE for ; Mon, 24 Nov 2003 17:15:22 -0800 (PST) Received: from VARK.homeunix.com (adsl-68-123-40-77.dsl.pltn13.pacbell.net [68.123.40.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4175943FE5 for ; Mon, 24 Nov 2003 17:15:19 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: from VARK.homeunix.com (localhost [127.0.0.1]) by VARK.homeunix.com (8.12.9/8.12.9) with ESMTP id hAP1D9en098320; Mon, 24 Nov 2003 17:13:09 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.homeunix.com (8.12.9/8.12.9/Submit) id hAP1D8FR098319; Mon, 24 Nov 2003 17:13:08 -0800 (PST) (envelope-from das@FreeBSD.ORG) Date: Mon, 24 Nov 2003 17:13:08 -0800 From: David Schultz To: Pawel Jakub Dawidek Message-ID: <20031125011308.GA98148@VARK.homeunix.com> Mail-Followup-To: Pawel Jakub Dawidek , freebsd-hackers@FreeBSD.ORG References: <20031124095852.GZ511@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031124095852.GZ511@garage.freebsd.pl> cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Size-independent byte order swapping functions. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2003 01:15:22 -0000 On Mon, Nov 24, 2003, Pawel Jakub Dawidek wrote: > If one is using strictly defined types as uint8_t, uint16_t, int32_t, etc. > those macros are helpful IMHO, because futher value size changes does not > affects code for byte order managing. This also does not hit perfromance, > because this should be resolved at compile-time. Cool, looks useful. > I'm not sure if dedicated epanic() is the best way to implement out-of-range > errors prevention - the more handy solution should cause compile error. See CTASSERT.