Solaris SPARC to Solaris x86 Porting Guide

protocols. The standard C library also provides the routines ntohl(),ntohs(),htonl() and

htons(), which convert numeric data between network byte order and host byte order. These

routines are appropriately implemented on the host platform to handle the conversion between host

and network byte order and must be used to shield the application from the underlying architecture.

Accessing the individual bytes of the numeric data using pointers

If an application uses individual bytes of a numeric data type to store and retrieve values, then you

might get different results due to the endianness of the underlying platform. In this case, the code is

not portable from Solaris SPARC to an x86 operating system.

Value 0X01020304 on x86 (little-endian format)

00000100 00000011 00000010 00000001

Memory address: 100 101 102 103

int flagVal = 0X01020304;

char *cptr = (char *)&flagVal;

printf("Val is %d\n(", *cptr);

Solution: In the preceding example, the little-endian machine will print 4, and the big-endian machine

will print 1. To make this code portable to multiplatform, use individual character-type variables to

store these values rather than using a numeric data type. Alternatively, you can use a structure

variable with individual fields for every value, and get and set these values using the structure field

names.

Application data storage

File systems are neutral to endianness in general, and swapping files between Solaris SPARC and

x86 is not an issue. Applications storing raw data that can be shared between platforms might be an

issue. For example, if an application on the Solaris SPARC platform writes the data structures in a raw

format to the files, then the data stored in these files would be endian-dependent. Reading or writing

these data files from an x86 processor-based machine can create issues regarding the endianness of

the data. The binary data (raw data) stored on a file is not transferable between the SPARC and x86

platforms.

Solution: Applications storing data that is shared between platforms can handle the endianness issue

in one of the following two ways:

• Store data in an application-defined, endian-neutral format using text files and strings.

• Select either the big-endian or little-endian convention and perform byte swapping (potentially using

enabling technology, such as XDR) when necessary.

Solaris environments range from personal productivity applications to major database management

systems from vendors including Oracle, Informix, and Sybase.

Shared memory implementation

Sharing memory with opposite-endian devices or processors constitutes data import and export. To

avoid the overhead of the attendant system call, while transferring data to high-speed devices through

an operating system, you can arrange to map the memory on a peripheral processor directly into an

application's address space. The most common example of shared memory mapped into an

application address space is the case of a graphics adapter with a frame buffer shared between the

host and the graphics processor.

Some peripheral buses lend themselves to shared memory approaches to interprocessor

communication. In general, some means of translating the data must be provided if the processors are

not of the same endianness.