From owner-freebsd-current Fri Oct 27 3:50:46 2000 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 8D18437B4C5 for ; Fri, 27 Oct 2000 03:50:41 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id VAA16212; Fri, 27 Oct 2000 21:50:09 +1100 Date: Fri, 27 Oct 2000 21:49:57 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Konstantin Chuguev Cc: Brian Somers , kargl@apl.washington.edu, freebsd-current@FreeBSD.ORG Subject: Re: platform byte order macros? In-Reply-To: <39F94740.66FCEB9E@dante.org.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 27 Oct 2000, Konstantin Chuguev wrote: > AFAICS ntoh[ls] and hton[ls] defined as asm instructions. This prevents > using them in const variables initialisation. They are normally implemented using asm, but their man page just hints that they are functions by giving prototypes for them. > I need to create a const unsigned char array[] (C source file) from quite > a big network byte ordered binary data. Although the data consists mainly NetBSD supports the ntohl family on constants, but only on some arches (at least in last year's version). It takes fancier macros to support constants. This gives an excuse to change the inline functions back to macros :-). > of bytes and 16- and 32-bit words, it is difficult in my case to use > u_char, u_int16_t and u_int32_t, as the order and the number of each type > does not fit to any possible C struct declaration. > Well, I can just create a network ordered byte array C declaration like > const unsigned char array[] = { , , ... }; > But for more efficient processing I would like to have something like > const unsigned char array[] = { > _4bytes(, , , ) > ... i.e. platform independent source code which would compile into > platform dependent object file. _4bytes, _2shorts and _1long are macros > produced for byte sequence in appropriate byte order. The macros need to > know the platform byte order, theoretically it can be one of 1234, 4321, > 2143. Theoretically there are 4! = 12 orders :-). > In endian.h I can see just huge line of comparisons to *_386 et. al., but > I cannot find any macros clearly decsribing the byte order. Am I wrong? There are macros LITTLE_ENDIAN, BIG_ENDIAN and PDP_ENDIAN to indicate 3 of the 12 possible orders. You can write your own conversion macros for these 3 orders. Other orders hopefully won't happen in practice. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message