Re: [Gnash-dev] Alignment in AMF data

[Justin Dick]

Have you guys considered making use of the endian macros, or environment variables from autoconf?  I've implemented htonll and ntohll macros using <byteswap.h> (specifically bswap_64) and the __BYTE_ORDER and __BIG_ENDIAN, etc macros, and I like that implementation because it generates only one copy, always aligns the data, uses tested system headers, and doesn't involve any function calls.  I usually prefer the standard, well-known htons/l/ll series of macros to even my own implementations because by using the system headers you gain quite a bit in terms of ease of portability, because you don't have to do anything at all or check your code for endianness issues. :)

I'm not an expert with autoconf, but I believe it will also generate macros or environment variables that provide a program with a knowledge of the endianness of it's platform.  Whether it's via gcc macros or autoconf, either way you also save a runtime check for endianness, since it's known at compile time.

Just my 2 cents.

Justin

On Fri, Oct 24, 2008 at 12:31 PM, Rob Savoye <address@hidden> wrote:

strk wrote:

> readNetworkShort and readNetworkLong use bitshifting, so single copy and
> byte order agnostic:

> Maybe we really want a readNetworkDouble ...

 We don't need to keep adding duplicate functions for code we already
have that is heavily tested! How you swap the bytes is less important as
long as it's byte order agnostic, like the current functions or macros.
For example, all the code in libamf uses the standard macros or
swapBytes() and works on both big endian and little endian, plus 64 bit
systems of both. There is rarely ever a good reason to duplicate
existing code with minor differences.

       - rob -

_______________________________________________
Gnash-dev mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/gnash-dev