|
First, I do not know of ANY processor that has not adopted the standard IEEE format for 4 byte and 8 byte floating point numbers. There should never be ANY problem with the floating point numbers themselves. Integers, yes.
But, there is the problem of alignment, where, depending on the architecture, floating point numbers MUST be aligned on an even 2, 4, or 8 byte boundary. So, compilers will even automatically byte pad structures, to be sure that every structure in an array of structures, is aligned. Thus, if you run the program below, depending on your architecture, the size of the given structure could be either 9, 12, or 16, depending on BOTH architecture and compiler. For instance, early Borland compilers were optimized for space instead of time, and allocated only 9 bytes for the structure below, and then, at runtime, copied floating point numbers to an aligned memory location before accessing. If you look at the assembly language output of your compiler, it can be quite interesting at times. As a general rule, NEVER pass structures between computers, and never read or write floating point numbers copied to buffers that are not known to be aligned. You must first copy them to know aligned areas using memcpy(). Hint: malloc() always returns memory, whose start is aligned for ALL data types. Don. #include <stdio.h> typedef struct mys_t { double d; char c; }; int main(int argc, char *argv[]) { mys_t mys; printf("sizeof(mys) = %d\n", sizeof(mys)); } On 2/17/07, Oguz Dilmac <> wrote:
|