[Asterisk-Dev] MP3 library vs. endian.h
chrisalbertson90278 at yahoo.com
Wed Jun 11 18:31:01 MST 2003
There is a more simple and portable way to do this that
works on Solaris/Linux/BSD and I'm sure others. Most
systems define a set of macros to convert byte order and these
marcos "work" becase they are defined differently in BE and LE
machines. I write code that works on Solaris/SPARC and
Solaris/i386 all the time and never need to use an #ifdef.
Every use of #if doubles your testing requirements as you
must test all combinitorial permutations (or else defer to
Microsoft's methods: "Why test? They'll buy anything, even if
Basically "hton" will take "whatever" and give you a B.E. result
while "ntoh" takes a BE and converts it to your cuurent byte order.
It's OK to chain these as one will always be defined as null.
With some small effort you can eliminate all #if and if() from
your code and depend on the system dot-h files to be correct.
Again, every "if" you remove halves your testing requirement
Here is a quote from the Solaris 9 man page: (remember "network
byte order" is B.E. as on a SPARC.)
byteorder, htonl, htons, ntohl, ntohs - convert values
between host and network byte order
uint32_t htonl(unint32_t hostlong);
uint16_t htons(uint16_t hostshort);
uint32_t ntohl(uint32_t netlong);
uint16_t ntohs(uint16_t netshort);
These routines convert 16 and 32 bit quantities between net-
work byte order and host byte order. On some architectures
these routines are defined as NULL macros in the include
file <netinet/in.h>. On other architectures, if their host
byte order is different from network byte order, these rou-
tines are functional....
--- Rafal Boni <rafal at pobox.com> wrote:
> [...sent once with the wrong From address; apologies to the moderator
> they see the other message and are confused...]
> The way the MP3 library is built, it always defaults to LE mode;
> this is because endian.h defines the LITTLE_ENDIAN macro even on
> BE systems (it's not supposed to be used to guess endianness by
> The attached patch gets rid of the hokey machine-detection stuff
> that never worked and instead uses BYTE_ORDER (I wanted to use
> __BYTE_ORDER or _BYTE_ORDER, but my Linux and NetBSD boxes could
> not agree about which was the right one :-/) to determine if we're
> a BE or LE system.
> This makes the MP3 codec load on my NetBSD/sparc64 (and I'd guess
> all other BE systems as well); I still haven't tested it, though.
> I still see SIGFPE's from the ILBC and LPC10 codes, but the issue
> there doesn't seem to be as clear-cut.
> Index: codecs/mp3/include/L3.h
> RCS file: /usr/cvsroot/asterisk/codecs/mp3/include/L3.h,v
> retrieving revision 184.108.40.206
> diff -u -r220.127.116.11 L3.h
> --- codecs/mp3/include/L3.h 12 Feb 2003 13:59:14 -0000 18.104.22.168
> +++ codecs/mp3/include/L3.h 11 Jun 2003 22:44:18 -0000
> @@ -36,27 +36,10 @@
> #define GLOBAL_GAIN_SCALE (4*15)
> /* #define GLOBAL_GAIN_SCALE 0 */
> -#ifdef _M_IX86
> -#define LITTLE_ENDIAN 1
> -#ifdef _M_ALPHA
> -#define LITTLE_ENDIAN 1
> -#ifdef sparc
> -#define LITTLE_ENDIAN 0
> -#ifndef LITTLE_ENDIAN
> -#error Layer III LITTLE_ENDIAN must be defined 0 or 1
> /*---- huffman lookup tables ---*/
> /* endian dependent !!! */
> -#if LITTLE_ENDIAN
> +#if BYTE_ORDER == LITTLE_ENDIAN
> typedef union
> int ptr;
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com
Home: 310-376-1029 chrisalbertson90278 at yahoo.com
Office: 310-336-5189 Christopher.J.Albertson at aero.org
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
More information about the asterisk-dev