This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

printing sizeof() values

I'm trying to print out sizeof() values for some of my structures. They are coming out incorrect. Here is a small table in which I've done this on different platforms:

Linux : sizeof(TChannel) = 1460
Windows: sizeof(TChannel) = 1460
8051 : sizeof(TChannel) = 1361

Are there byte-alignment issues perhaps? I have both Linux and Windows defaulting to a 1-byte boundary for byte alignment in structures. Does the 8051 default to something different?

Here's my code for the 8051:
Debugf( "sizeof(TChannel) = %u\r\n", sizeof( TChannel ) );

I've tried %u, %d, %lu, %bu, %X but can't get the right value. Here's my Debugf() function in case that might be messing things up:

void Debugf(BYTE* format, ...)
{
#ifdef DEBUG
xdata BYTE buf[64];
va_list arglist;
va_start (arglist,format);
vsprintf(buf,format,arglist);
va_end (arglist);
SendSerialData( buf, strlen( buf ) );
#endif
}

I don't think the problem is in my SendSerialData() function as that seems to work well.

Any ideas?

Parents
  • ...in Windows a BOOL is 4 bytes...
    ...UINT on windows is 4 bytes...


    By "Windows," I presume you mean Win95/98/NT/2k/XP..?

    All of these are 32-bit systems, so 4 bytes should come as no surprise whatsoever - it's 32 bits!!

    That's why I keep saying that names like "UINT" should be avoided - they convey no information at all as to the intended size of the type.
    I always use names like U8, U16, U32 so that the size is instantly, clearly, and unambiguously obvious at a glance.


    BTW: The internal representation of 'C' data types is primarily an issue for the Compiler rather than the operating system - so rather than saying "in Windows..." you should say "in MSVC..." or whatever.
    (Having said that, of course, it makes sense for the Compiler to follow the "natural" representation of the underlying architecture...)

Reply
  • ...in Windows a BOOL is 4 bytes...
    ...UINT on windows is 4 bytes...


    By "Windows," I presume you mean Win95/98/NT/2k/XP..?

    All of these are 32-bit systems, so 4 bytes should come as no surprise whatsoever - it's 32 bits!!

    That's why I keep saying that names like "UINT" should be avoided - they convey no information at all as to the intended size of the type.
    I always use names like U8, U16, U32 so that the size is instantly, clearly, and unambiguously obvious at a glance.


    BTW: The internal representation of 'C' data types is primarily an issue for the Compiler rather than the operating system - so rather than saying "in Windows..." you should say "in MSVC..." or whatever.
    (Having said that, of course, it makes sense for the Compiler to follow the "natural" representation of the underlying architecture...)

Children
  • Hey! U8, U16, U32 are mine! All mine! :-)

    I wonder why the OP didn't typedef Bool to bit a bit instead of char?

  • I wonder why the OP didn't typedef Bool to bit a bit instead of char?


    I didn't do this because I couldn't get the type 'bit' to be declared in xdata. The compiler choked (I forget the error message).

    And since I have boolean values in my structures, which are in xdata, BOOL was defined as unsigned char.


    On the 8051, aligment is to 1 byte thus all structs are "packed". On a 16-bit machine typically padded to 2 bytes, with a 32-bit machine padding to 4 usually.


    Yes, the following will force MSVC (on a 32-bit Intel machine) to align to 1 byte boundaries, to match that of the 8051.

    #ifdef _WINDOWS_
    #pragma pack (1)
    #endif

    structs go here

    As you might have guessed, this is a common header file that both my GUI on Windows and the firmware on the 8051 share, so I can transfer these structures back and forth via the serial port. And yes, I do all the endian conversion on the GUI side; it works just fine.

  • I didn't do this because I couldn't get the type 'bit' to be declared in xdata. The compiler choked (I forget the error message).

    Of course it choked, bit data is a not only an 8051 type but a memory space, that space is at DATA address 0x20 and extends for some number of bytes that can be treated as true bit types. It is a contradiction to attempt an XDATA bit var. For structs (or do you mean C bit-fields?) you must use the type unsigned char for the next most efficient access (remember, you pay a penalty for the signed versions).