On Thu, 19 Oct 2006, Shao Wu wrote:
Interesting... but how does it work for generic application data? the way my application work is to encode the file to indicate data are stored in little-endian or big-endian format. The program accessing the data will do endian convertion if necessary (there is a data dictionary encoding the real type), or simply mmap if they both have the same byte-ordering.
Just _define_ your application data format. See xdr(3NSL) for how this can be done in platform-independent fashion.
If you insist on using "typedef struct { ... } my_compound_t;" then you'll always run into endianness conversion issues (and data type size/alignment differences). If you start with a platform-independent data representation then you don't even have to think about it.
Yes, there might be some speed impact; is it worth starting to code with the uttermost possible optimization in, or first get working code ?
Generically, I'd always mmap, but use accessor functions/macros to get at the members of my data structure. That way, endianness issues can easily be hidden. It's like ntohl(), see byteorder(3SOCKET), which evaluates to a no-op if the platform's byteorder happens to be equal to the host byte order.
The problem has been solved many times in the past. As said, see the documentation, manpages for xdr(3NSL) and/or byteorder(3SOCKET), or for kernel drivers see ddi_device_acc_attr(9S). The library functions for endian-independent data access can be assumed to be optimized for the platform, although they might not reach the level of inline assembly, of course. But as said, functional first, optimized later ?
Best wishes, FrankH. _______________________________________________ opensolaris-discuss mailing list [email protected]
