Hi John,
What I've done in the past to get around this problem is to use
bitfields. That way I've mapped out entire UART's and other hardware in
C struct's for other hardware and compilers. The only problem is that
the resulting typedef's are a bit cryptic to say the least, but all that
cryptic stuff can be made to disappear in usage. Have a look at what I
mean :
typedef struct
{
Char nameField[9];
Char padding[3];
} nameStruct;
typedef struct
{
UInt32 padding1[2];
UInt32 padding2:8;
UInt32 valueTwoField:16;
UInt32 padding3:8;
} valueStruct;
typedef struct
{
UInt32 padding1[2];
UInt32 padding2:24;
UInt32 textField:8;
} textStruct;
typedef union
{
nameStruct nameStruct;
valueStruct valueStruct;
textStruct textStruct;
} mixedUnion;
typedef struct
{
UInt32 dWordOne;
UInt16 valueOne;
mixedUnion mixedUnion;
} MyType;
#define name mixedUnion.nameStruct.nameField
#define valueTwo mixedUnion.valueStruct.valueTwoField
#define text mixedUnion.textStruct.textField
void foo(void)
{
MyType myType;
// Initialize this struct with some known data so it's
// easy to see what's going on when viewing raw memory in
// the debugger
memset(&myType,0xCC,sizeof(myType));
// Use the struct's, union's and #define's from above in
// simple and easy to understand expressions
myType.dWordOne=1;
myType.valueOne=2;
myType.name[0]='a';
myType.valueTwo=3;
myType.text='b';
}
See, I told you, it's a whole lot of extra typedef's but once you
understand the general idea, they're understandable. But have a look at
how easy it is to use them in foo(). Use the debugger to view the
changes in memory at each step, and I think this does exactly what you
intended with your original struct.
The only teenie weenie price you have to pay when using this trick is
that inspecting instances of this struct in the debugger is a bit more
obscure now due to the whole union/struct shebang.
Oh, uhm, did I also mention that this trick is highly platform
dependent... but what the heck, it's not like you intend your code to
compile for other processors as well, do you ?
Stay alive,
Aloy Ambergen
John Jenusaitis wrote:
I have the following structure,
typedef struct
{
UInt32 dWordOne
UInt16 valueOne
Char name[9]
UInt16 valueTwo
Char text
} MyType
My question is whether Palm adds a byte padding to fit the structure
into a certain bounds? When I cast my record to this structure, the
data that follows the fixed length string (name[9]), is off by one byte.
It appears that an extra byte is being added, following the string.
Does anyone know if this is correct and a way to handle the issue?
Thanks
John
--
For information on using the ACCESS Developer Forums, or to unsubscribe, please
see http://www.access-company.com/developers/forums/
